Development >  Utilities >  Patches >  Patch test  

Ergonomics |  Index

When specific developments are carried out by modifying the standard elements, the lowest level element that has been modified must be protected by an activity code starting with X, Y or Z (for example, the screen field rather than the section or the screen itself). In addition, the use of an activity code is not necessary when SPE or SPX actions (or actions starting with X, Y or Z) are used in a screen.

However, such a development requires verifications upon the installation of standard patches on a modified folder. Indeed, it is necessary to ensure that the patched elements do not conflict with modified elements (in this case, the elements, protected by an activity code, are not patched, and this can be problematic).

This function is used to carry out, in an automatic fashion, a detection of potential conflicts linked to a set of patch files located in a directory. More precisely, it performs the following actions:

• reading all the patches located in a directory
• for each patched object, the function looks if there is a potential conflict due to a specific activity code (unless this specific activity code was put at the head of the patch as meant to be overwritten)
• it generates a log file detailing the possible conflicts.

 Thus, when specific developments have been carried out and a standard (or specific) patch list must be installed, all the user has to do is launch this function:

• if no collisions are detected, there is normally no risk (if the specific development standards have been correctly followed).
• if there are conflicts, it is necessary to focus on the detected conflicts (which normally account for only a minor part of the cases).

If multiple patch lists must be installed, it is possible to copy (for the duration of the test) the totality of the corresponding files in the same directory: the only limitation for the tester is 1,000 simultaneous patch files all the corresponding files in the same directory:

The tests performed are the following:

• the screens, tables, objects, functions, data types, inquiries, windows, actions patched and globally protected by an activity code.
• the fields and sections in a screen, the options and variables in a function, the fields and the indexes in a table, the buttons in a window, the left lists (browser tab), tabs, and tables linked in an object, when these elements are protected by an activity code that do not protect the element of higher level.
• the processings and reports locally installed in a folder for which the patch may not be effective.

The conflicts linked to the specific activity codes (starting with X, Y or Z) are all detected, except those that correspond to activity codes given in the patch header (since in this case it is a specific patch, it is understood that the patch will be applied).

In order to allow this type of test when the update has not been carried out by the patch file installation, but by the installation of a new sub-version, a list of files named List_nn.dat will be found from the version 134 CD, in dedicated directories (the sub-directories P132, P133, P134… of the directory named X3patch), and which does not contain the nn patch list, but only the list of objects affected by the patch list, all of which to facilitate the identification of potential conflicts existing in a list. The following example explains the use:

• imagine that the folder that is to be updated to version 134, is at version 132 patched to the level 12 list.
• the upgrade to version 134 requires the installation of the patches 13 to 18 (those which are required to upgrade to version 133: the corresponding List_nn files are in the directory X3patch\P133 on the CD), and the patches 19 to 31 (those that are required for the upgrade to version 134: the corresponding List_nn files are found in the X3patch\P134 directory on the CD).
• it is then sufficient to copy the List_13.dat to List_31.dat files to a temporary directory, then use the patch test function by giving a name to this directory. If the conflicts are highlighted, the element in conflict will be in the log file along with the corresponding list number; it will be possible to test the list in question to provide further information.

Warning, this utility only provides information on potential conflicts, it is not capable of identifying what should be modified in the element in order that all works correctly. On the other hand it is possible to carry out tests on the contentious elements by using the comparison function on the corresponding elements between a patched and a non-patched function.