Development > Utilities > Patches > Patch creation 

This function is used to create an archive containing developments created in a given folder (the current folder by default), and a certain number of setup elements. This function is of particular interest if it is necessary to transfer to a live folder a set of consistent modifications carried out in a setup or test folder.

In addition to the possibility of grouping together a set of elements, this patch generation is used to circumvent the single server or interconnected server constraint that necessitates the use of the Copy button.

The principle of this function is to extract the data dictionary elements of a folder, plus other data (in principle, the setup data in limited quantities, because this format is not overly compact). All of the elements extracted in this way are archived in a file that can be reintegrated into another folder by using the patch integration function. The multilingual aspect of the dictionary is managed by this utility, it being possible to transfer the messages linked to the patched elements in several languages.

Each extracted element is identified both by a code that defines the type of patched element (a screen, a report, data from a table...) and by a supplementary information element (the code of the screen, of the object, a selection criterion....).

This function is used:

  • by the standard development teams to create correction patches or additional functional deliveries,
  • by partners having carried out vertical developments to install additional modules,
  • by developers to transfer specific developments which have been carried out.

Screen management

Entry screen


The following is defined in the entry screen:

  • the general parameters of the patch,
  • the language codes for which the extraction of texts must be carried out,
  • the list of elements to be patched in a grid.

The entry is carried out on a single tab.




The following fields are present on this tab :


  • field AW


  • Destination type (field TYPEXP)


  • File name (field VOLFIL)


Type of patch

  • Type of patch (field TYPPTC)

The patch type can take the following values :

  • Standard : this is a patch that is likely to be installed in a list of folders that will be given on the integration, this list integrating in principle the supervisor folder. In the majority of cases (including the specific/custom and vertical developments), it is the type of patch to be used. In fact, the delivery of specific/custom or vertical developments is not conditioned by the type of patch, but by the list of activity codes that are given in the corresponding grid.
  • Supervisor  : this is a patch that will only be integrated in the supervisor folder. This type is used in order to integrate pre-parameterization elements (import/export templates, automatic journals, Workflow rules...) that may have been modified in the different folders. To avoid the deletion of the modification carried out, only the supervisor folder will be updated. This is used to have the pararmeterization values up to date in the case of the creation of a new folder and also used to manually update by copy in each folder after having used the existing comparison utilities.
  • Vertical : this is a patch identical to the standard patch, but it is used, when a screen is patched, to delete specific/custom actions (SPV) not present in the patch.
  •  Specific : this is a patch identical to the standard patch, but it is used, when a screen is patched, to delete specific/custom actions (SPE) not present in the patch.

In the previous versions, a patch of the type SPX is used to delete an SPE action present in a screen. From version 150, these last two types of patch, much more flexible, are used to update the SPE actions (which previously existed) and the SPV action (which are new).

Important note : The patches containing the documentation elements are processed in a particular fashion, described in the corresponding appendix.

Table Languages

This table is used to define the languages that should be patched.

In fact, all the data dictionary texts (defined by the code type ATX) are stored in a separate table (ATEXTE table) and are identified by a number (less than 100,000 for standard texts, greater than that for others). These texts are transferred by patch in their literal form (the number has no meaning since it may vary) in the different languages. Therefore this table gives the list of languages used for inclusion with the texts.

Block number 6

  • Comment (field COMMENT)

This information comment is used to describe the patch file (from the point of view of its finality or its contents). It will be visible in the patch integration log file.

It is the name of the folder from which the patch elements will be extracted.

  • Minimum version (field VERSION)

This minimum version code is used to avoid the integration of the patch with an inferior version in an application.

  • Product (field PRODUIT)

Code not entered identifying the adonix software from which the patch is extracted.

Table Objects

  • Type (field TYPOBJ)

This table is used to enter a list of objects to be patched. This list is identified by an object type and a name. The definition of the different types and the meaning of the name are given in an appendix.

  • Object name (field NOMOBJ)

The element key entered here for which the code has been entered or an additional information (condition in the case of a data patch). It should be noted that if the key for the record to be patched is in several parts, these are separated by the tilde character ( ~ ).

  • Title (field INTITOBJ)

It used to define a name associated with each record.

Table Activity codes

This grid is used to enter a list of specific/custom or vertical activity codes (i.e. starting with X,Y or Z).

Once a patch integrating developments of this type is to be created, it is mandatory to define the activity codes involved. In fact, the dictionary elements carrying the non listed specific/custom activity codes will be ignored on the integration of the patch. This precaution is mandatory, because if not a standard patch could update an object marked by a custom/specific or vertical activity code. It is precisely the fact that no specific/custom activity code has been given in the standard patch header that makes it possible to manage this event.

These activity codes are therefore not a means of filtering the extraction of the objects in the patch indicate that the elements marked by these specific/custom activity codes will be updated on the integration of the patch. The loading of the elements marked by these activity codes can be made using a function accessible by right click in the grid defining the contents of the patch.



Functions accessed by right click on the grid


This function is used to pre-load in the grid all the folder elements marked by the activity codes listed in the corresponding grid.

Standard Rerouting Action

This function is used to verify if the object of the current line is or not the same in two folders. A window then opens in order to enter the two folder codes. Once this window is opened, the comparison is performed and a log file window gives the result. If the name of the element is not indicated as different, the two element are the same in the compared folders.

NB: it is possible that the comparison cannot be made on some object types. A message is thus displayed in the log file.

Standard Rerouting Action

This function is used to verify whether all the objects in the patch are the same in two folders. A window then opens in order to enter the two folder codes. Once this window is opened, the comparison is performed and a log file window gives the result.

Standard Rerouting Action

This function is used to call up a setup model in order to enter a list of patches of type AAA (a line by data model indicated in the screen).

Warning: unlike the functioning obtained when using the setup copy function, here only the AAA lines are generated (the APH line describing the model is not included). Moreover, the legislation code is not entered at this moment and any filter on the legislation is not applied normally here.

However it is possible to generate an AAA line for a unitary data model via right click Data model on field Object name. It is then possible to access a selection window used to choose the model, legislation, key or selection formula in order to create a line integrating all the elements.




Element types that can be patched

This table is used to enter a list of object to be patched. This list is identified by an object type and a name. The definition of the various types and the meaning of the name are given here: The Rank column is used to know the order of the element types in the patch (see paragraph below). Elements with rank 100 in the grid are always at the end of the patch (in alphabetical order of element codes).






 Lines arising from a setup model

Specific format, see corresponding section



Batch recurring task

Recurring task code



BI Fact table

Table code



Group of tasks

Group code



BI Dimension

Dimension code



BI Datamart

Datamart code



Report Business Objects

Report code



Batch task

Task code



BI Synchronization rule

Code of the rule



Control table

Table code




Inquiry code



Access codes

Dealt with in the form of a condition (CODACS="value")




Action code



Definition of an activity code

Activity code



Description of a processing (dictionary)

Processing name



Documentation links

Type ~ Element code



Contents of a miscellaneous table

Table number



Functional help (all paragraphs)

Type ~ Help code



Parameter (both its definition and value if they exist at the general level)

Parameter code


Sales Management

Setup of a miscellaneous table

Table number



Processing (only in its compiled form)

Processing name



Field help

Help code



Import/export sequencing

Dealt with in the form of a condition (CODE="value")




Function code



Global variable

Variable name



BI Hierarchy

Hierarchy code



Purge formulas

Formula code



BI predefined condition

Condition code



Query tool

Code for the query



SQL query tool

Code of the SQL query



Graphical requester

Code for the query




Screen code



Local menu

Local menu number




Navigation code



Definition of a counter:

Code of the counter



Widget Netvibes setups

Object code for widget



Definition of an object

Code of the object



Import/export template

Template code



Object properties

Code of the object



Setup models

Model code



Graphical process

Process code



Report definition in the dictionary

Report code



Conditioned style

Dealt with in the form of a condition (COD="value")



Description of a sub-program in the dictionary

Name of the sub-program



Presentation style

Style code



Table definition (the contents are not transferred, the update of the structure is made without losing common data)

Table code




Transaction code



Data type

Code of the type




URL code




Code of the view



Workflow rule

Code of the Workflow rule



Web service

Publication name



Window definition

Code of the window



Workflow data model

Model code



Workflow assignment rule

Code of the assignment rule



Setup of the Workflow workbench

Code of the workbench



 BIAR objects

Object code



Element of the client interface (xsl, image, miscellaneous file)

File path



Crystal Reports report (file with .rpt extension)

Report name



Request to run a processing

Processing name



Automatic journals

Document code



Statistical trigger

Trigger code



Statistical code

Statistical code



Complete structure and contents of a table (excluding its "dictionary" definition).
The global patch of a table is a flat backup of this file: similar to a .dat file of a table backup in the SVG directory. Not all the links to this table are taken into account and especially the translatable texts contained in the ATEXTRA table.

Table code



Formula table

Formula code



Source of a processing (the processing will be compiled on patch installation)

Processing name



Text file (in the TXT directory)

Text name


Table abbreviation

Partial contents of the table

Extraction condition (expressed in the form of a Where clause)


Important notes

Total transfer of data from a table

The TAB code is used to transfer the data in a table, by reloading it in the database with its structure and its data. On the other hand, the dictionary elements corresponding to this table are not created, which means that it may not be visible. Also, this code is useful when re-loading a table already created in the folders to be patched, where the structure has not changed. If this is not the case, it is necessary to place two lines in the patch definition : the first line concerns the table definition (ATB XXXXX), the second line concerns its content (TAB XXXXX). Even if they are not sorted in this entry order, the patch function will replace them in the order above. At the patch integration, the table will be created in the dictionary and in the database, if it does not already exist (if not, its structure will be updated if it has changed). Then the table will be reloaded with the data.

Partial transfer of the data in a table.

The possibility to transfer the partial contents of a table is obtained by giving the abbreviation in the Type column of the table, and by indicating in the Name column a logic condition that will be used for the extraction of the initial folder and for the integration in the target folder. It is important to note that the data extracted in this way can modify the existing data with the same keys, or to create new data. On the other hand, and for reasons of security, in no case will there be deletion of data during the integration of a patch. In this way, for example, if the following situation is considered, for the country table (abbreviation TCY) :

Initial folder

Target folder

Country code

Country name

Country code

Country name






United Arab Emirates

















If in the patch the line with TCY is indicated and the condition CRY = "AL", the patch will only contain the line corresponding to Albania, and the integration of the patch in the target folder will rewrite AL, Germany and replace it with AL, Albania.

If indicated in the patch is a line with TCY and the condition pat(CRY,"A*"), the patch will contain 4 lines AD, AE, AF and AR. On integration, the record AE, United Arab Emirates and the record AR, Argentina will be created, the AL, Germany will be replaced by Albania and keep A, Afghanistan and AU, Australia, that existed already in the target folder and were not delivered in the patch.

If in the patch there is a line with TCY and the condition find(CRY,"AD","AE","AL"), the result will be the same, except for AR, Argentina, which would not have been transferred.

The only way to delete data consists in:

  • Either globally replacing the contents of a complete table (TAB type patch)
  • Or supplying a processing via the EXE code (see below). For example, in order to be sure for the countries starting with an A, that only the countries with codes AD, AE or AL remained on the list, a processing would have been delivered (called MAJPATCHnnn for example), which would contain the lines described in the example below.

Running a processing

One specific case must be mentioned: The EXE code, which makes it possible to give a name to a processing to be run. This processing is run at the end of the patch integration (it may exist beforehand or be delivered in the patch itself, since the execution is only carried out at the end of the integration).

This processing must contain a sub-program PATCH, with a setup that is the folder code. This is the sub-program that will be run. In this way, for the situation above, the following program is obtained :

Value Char NOMDOS
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0

In this way it can be see that it is necessary to declare the tables in this sub-program while considering the fact that they must be declared in a folder that is not necessarily the current folder ( It is the syntax, Local file = FOLDNAME + ".TABLENAME", that ensures it).

Generic processings to be run

When patches are carried out on model elements of the user interface (model screens used to create transaction windows), the screens concerned need to be revalidated.

This revalidation can be performed by declaring the running of the appropriate processing in the maintenance. The standard processings to be started depending on the type of patched element can be found here below:

 Patched element

to be launched


Screen used as the basis for an inquiry which can be set up.


Validation of all the inquiry screens

Presentation styles


Generation of the styles

System transaction


Validation of the system transactions

Statistical setups


Revalidation of all the statistics

Basic screen of a transaction on the XXX object


Revalidation of the transactions associated with the object

It should be noted that this type of functionality can also be carried out within the framework of a specific development (simply add the PATCH sub-program as specified in the previous paragraph).

Documentation patch

The structure of the data in the documentation slightly differs. In effect, the following default rules are applied on folder creation and revalidation:

  • the documentation texts and files (tables ADOCBLB and ADOCCLB) are entered in the supervisor folder and are not transferred to the dependent folders (it is nevertheless possible to create local help texts for a folder that will be stored locally).
  • the documentation structure (documentation links, that are nearly dictionary elements, and paragraph structures) is stored in each folder and copied to those folders located below in case of revalidation (while complying with the vertical or specific activity codes that may have been defined in a child folder).

Thus the principle is as follows when integrating a doc patch (ADO type):

  • the documentation structure can be integrated to all the folders listed when applying the patch, irrespective of the patch type (based on the list of folders supplied on integration)
  • the texts and files are only integrated to the supervisor folder if the patch type is Supervisor (this is the case for the standard doc patches). In the event of a different patch type, the texts and files are integrated to all the folders.
  • the ADF type patch (links) can be integrated to all the folders, even if the patch has the Supervisor type.

Naming of the patch files

The patch integration checks the application sequencing of the patch files, whenever they include a numerical sequencing in their name. It is recommended to name the patch files using a name defined under the form X_yyyy_zzz.dat, with the following meaning :

  • X is a character (different from P, since P is used to specify standard patches) that identifies the patch type
  • yyyy is a sequential number (in principle starting at 0001).
  • zzz is an identifier for the version to be integrated.

If this standard is applied, during the integration of a group of patch files in a directory, the following controls will be made :

  • files from different versions are not mixed during the same integration
  • it is not possible to skip a sequential number if patches identified by the same character and the same version number have already been integrated. In this way for example, if the patch Z_0005_150.dat has been integrated, if an attempt to integrate patch Z_0007.140.dat is made without first having integrated the Z_0006_150.dat patch, an error message is displayed on integration.

Order of the elements in a patch file

When a patch file is created, the rule is for the elements contained in said patch file to form a consistent whole which leaves the folder consistent after it has been applied. In particular, if a new function is created by patch, be it defined by an action, a window, a screen, a table and two processings, it seems logical for all these elements to be part of the patch.

When some elements are used to constitute a patch file, the creation function sorts them in a specific order of types, so as to avoid integration errors. For instance, if a window is integrated before the screens making it up, the error Screen does not exist will occur on validation. As a consequence the data types are always integrated before the screens and tables, the screens before the windows, and so on and so forth.

The order used on generating the patch matches the rank specified in the grid below: It is also the proposal order that appears in the automatic patch.function.

Let us underline the fact that it is impossible to solve all the possible conflicts. For instance, a data type can refer to an action, that may refer to a window, that may refer to a screen, that may refer to this data type. To solve this situation of conflict (although rare), it may be necessary to break down the patch file into two files (for instance, the first file supplying all the elements with a data type that does not refer to the action, the second file supplying the data type that integrates the action).

Non patched elements in the dictionary

When installing a patch containing dictionary elements, some fields, considered as dictionary elements that can be set up, are complied with irrespective of their protections by means of activity codes. This is the case of a default destination in a report.

A detailed technical annex lists these fields.

Specific format for AAA elements

A patch of AAA type corresponds to a line coming from a setup model. It uses a specific format for the element code. This format is one of the two following:



In these lines:

  • MODELE corresponds to the data model used to describe the tables to extract
  • CODE_LEG corresponds to the legislation code, which can be empty (in this case, two ~ are place one after the other)
  • CODE_TRS corresponds to the transaction code, which can also be empty
  • FORMULE_SELECTION is a filter condition. Any text chain must be put "in double quotes" since the formula is put in 'simple quotes'.
  • CLE~SOUS_CLE~SOUS_SOUS_CLE (the number of sub-keys being variable) corresponds to the specific case when it is required to select a key value corresponding to the model main table. It is only possible when calling up a model (AAA code) from the patch creation and then opening the window making it possible to select the model and enter the key by direct search.


By default, the following reports are associated to the function :

 PRTSCR : Screen print

This can be changed by a different setup.

Batch task

This function can be executed in batch mode, but no dedicated standard task is delivered to execute it.

Specific Buttons

This function is used to recall the list of elements contained in a patch file in order to complete it if needed and recreate a patch file. The window that opens then is used to select the patch file to read.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

…. : non-existent directory

The access path for the patch file does not exist.

Object type is incorrect

The object type does not correspond either to one of the predefined objects or nor to the abbreviation in an existing table.

.....Dictionary XXX record non-existent

An attempt has been made to extract an object from a non-existent dictionary.

Incorrect value

The extraction condition associated with the data extraction from a table contains incorrect syntax.

Tables used

SEEREFERTTO Refer to documentation Implementation