Additional data upgrade information
This section contains additional data upgrade information that you may find useful during your upgrade to Microsoft Dynamics AX 2009.
When is data upgrade necessary?
Data upgrade is necessary in the following situations:
When a table is deleted and the data must be saved
When a field is deleted and the data must be saved
When unique indexes are added or changed
When a non-unique index is changed to a unique index
When the location where data is stored is moved—for example, when data is moved from one field to another
When inconsistencies of old data are fixed
When new fields need to be populated with existing data
What triggers the data upgrade process?
Microsoft Dynamics AX 2009 checks the SYSSETUPLOG table to see if information is stored in the table. If the table does not contain information, this indicates that a new installation of Microsoft Dynamics AX is being performed, and the Installation checklist is displayed.
If the SYSSETUPLOG table contains information, Microsoft Dynamics AX runs a script resembling the SQL script SELECT LASTONLY FROM SYSSETUPLOG. The script returns information including the last successfully launched version of the product, the application build value, and the kernel build value. If these values all match those of the current installation, Microsoft Dynamics AX 2009 starts in the normal way. If any values are different, the Upgrade checklist is displayed.
When is a manual data upgrade necessary?
Manual data upgrade may be necessary if you have created new tables or fields that depend on data in tables or fields that have been deleted or moved.
You can locate deleted tables and fields by searching for application objects prefaced with DEL_.
Deleted tables and fields
Some objects in previous versions might be removed during the upgrade to Microsoft Dynamics AX 2009. These objects are given a prefix of DEL_, and they are assigned to specific configuration keys. When these configuration keys (Keep update objects 4.0 and Keep update objects 4.1) are unselected in the Configuration form (Administration > Setup > System > Configuration), the objects assigned to those configuration keys are deleted. Never manually delete tables and fields from your database.
What happens to renamed application objects during data upgrade?
Microsoft Dynamics AX tables and fields are identification-based rather than name-based, which means that they have unique identification codes and should not cause problems during the data upgrade process. Renamed application objects might cause issues with data upgrade only when the objects are referenced in your X++ code. If you reference the renamed application objects in your X++ code, you might get compile errors during the upgrade process, which means that you'll need to modify your code to use the correct objects so that you can properly compile.
What happens to deleted application objects during data upgrade?
The data upgrade process uses DEL_ as a special prefix for some application objects, such as tables, that will be deleted in the Microsoft Dynamics AX 2009 version.
The DEL_ tables and fields are necessary for data upgrade because 'old' table structures need to be maintained until the data upgrade is completed so that data is not lost.
When an object with a DEL_ prefix is introduced because of a schema change in Microsoft Dynamics AX 2009 or because you have changed your modifications, the Microsoft Dynamics AX 2009 upgrade scripts handle the changes in the standard application. One example of this is when the ReleaseUpdateDB_<old version>to<new version> class moves the fields and X++ code to the table that replaces the one with the DEL_ prefix.
The configuration keys SysDeletedObjects30 and SysDeleteObjects40 are assigned to application objects that have the DEL_ prefix.
Note
If you have X++ code that references an application object that has the DEL_ prefix, you will need to re-evaluate the existing modifications and update them to use the new object that replaces the DEL_ object.