Testing the consistency of your data during an upgrade project is critical to the success of your project. In the first test runs of the upgrade, it is common to experience data consistency errors both during and after the upgrade process. Follow these general guidelines to quickly find the root cause of your issues and determine the best course of action for the next run of your upgrade testing. These steps assume that you have gone all the way through the Data upgrade cockpit within the Dynamics AX 2012 environment.
One of the very first steps would be to look at the Generate Mapping window and see if there are any mapping errors for tables. Any mapping error will cause the table to not be copied during the bulk copy process.
Use a Divide-and-Conquer approach – Determine if the error happened on the Source or Target side of the Upgrade Process.
The first step in troubleshooting a data consistency issue is to determine if the issue happened on either side of the Upgrade Process.
1. Look at the DirectSQL field in the ReleaseUpdateBulkCopyTable on the table in which the error was found. This field stores the SQL Statement that the Upgrade Framework generated during Bulk Copy
If no statement can be found for the table in question, the table was not copied over to the Target System. Verify that all the mappings for that table are correct.
2. Run the statement against the Source Database and check the results. This is a snapshot of the data in this table as it was copied over to the target system.
3. Analyze the data in the results obtained by the SQL Statement. There are two options:
a. The data is not in a good state – Then the error happened in the Source side of the Upgrade Process
b. The data looks correct – Then the error happened on the Target side of the Upgrade Process
Troubleshooting Errors in the Source System
Troubleshooting Errors in the Target System
Once determined that the data was copied correctly during Bulk Copy, we will need to find which scripts worked against the table in question. This information can be obtained by looking into the ReleaseUpdateScriptsUsedTables and ReleaseUpdateScripts tables. This will considerably narrow the list of scripts down to a more manageable amount.
From this point on, we can search within the scripts to find what kind of operations they are doing on the script. It is also useful to look into the dependency tree to find out the chain of scripts involved in a table’s upgrade process. Look into the ReleaseUpdateScripts and ReleaseUpdateScriptDependency table to get this information.