Extracting a delta means that DE should analyze the changes between two files (there might be many sets of two files each, if you run in folder mode), and create both a delta file (the changes) and a delta report that shows these changes.
The image below shows an example of the necessary Action Parameters to extract a delta:
Action Parameters
Mode: | In this example the DE is asked to work on a Single File. |
Original: | This is the file before the changes took place. If you ran in Folder Mode this would be a folder. |
Revision 1: | This is the file with the changes you want to extract. If you ran in Folder Mode this would be a folder. |
Revision 2: | Not needed to extract a delta. |
Output: | Not needed to extract a delta. |
Delta: | This is the xml file that stores the delta. If you ran in Folder Mode this would be a folder. Observe that a corresponding HTML file will be created. This is the file containing the delta report. |
Notes: | This (optional) note will be written to the delta report. |
Should be F1 Table
After setting up the Action Parameters you click extract:
Extract Button
The log window will display the result of the process:
The Log Window
If you click the Report hyperlink, the delta report will be displayed:
The Delta Report. Note that this is only a little section of the report
The result of an extract, the delta (xml) file, can be distributed to another person who needs to merge/apply the extracted changes to for example a Customized file. The source code, the Original and the Revision 1 files, will not have to be distributed.
Even though not absolutely necessary for the receiver to apply the changes, you should also send the report .html file so that the receiver can study the changes before applying them.
DE will only recognize a subset of supported programming languages. Even if we try to increase this percentage, we will probably not be able to cover all coding of IFS Applications. A typical parse problem could look like this in the log window:
A parser error in the log window
Observe that the line number is exactly the place in the file where parsing failed. The statement (starting) in this line should be bug-reported. In the example above, it would seem at first that DE simply doesn’t understand “transaction”, but if we look carefully, we can see that the error line is actually telling where parsing stopped, which means that the parser did not expect “transaction” in the location in which it was found. The problem might therefore be something else.