Code upgrade: Examples

Two code upgrade scenarios are described in this topic:

• Scenario 1: Upgrading the CustTable table

  Code modifications typically involve the addition of one or more fields to an existing table.

• Scenario 2: Upgrading the VendTable form

  Another typical modification is to add a button to an existing form.

Table and form objects are discussed in separate examples because they are treated differently during an upgrade.

Forms (as well as reports) are designed as a single entity. This means that any modification to a form, whether the addition of a button or a change in a method, requires the whole form to be updated.

All other types of application objects (tables, classes, menus, and so on) consist of a number of components, each of them shown as a node in the Application Object Tree (AOT). If only one table method has been modified, only that method is considered during the upgrade process.

The field names and numbers used in the following scenarios are fictional examples that do not necessarily correspond to any real-life situation. The examples use a SYS layer and a USR layer. The modifications might also be in another layer, or even in several layers.

Scenario 1: Upgrading the CustTable table

In this scenario, Microsoft Dynamics AX has been installed as an upgrade to an existing Microsoft Dynamics AX 3.0 installation.

• In the SYS layer, CustTable has two fields, A and B.
  In the SYS layer, CustTable has 4 fields, A, B, C and D. That is, two fields have been added in the new version.

• In the USR layer, CustTable has one field, CompanyLogo.
  In the USR layer, CustTable has one field, CompanyLogo. The USR layers in the new and old versions are identical.

When the Create upgrade project algorithm is applied to each field in the CustTable table, fields A and B will be ignored since both existed in Microsoft Dynamics AX 3.0. No upgrade is necessary.

The same applies for the new fields, C and D: there are no changes to the fields as compared to the previous version, since the fields did not exist then. Therefore, no upgrade is required.

Similarly, the field CompanyLogo is not relevant for the upgrade. There are no conflicts with the previous version.

The final result of the Create upgrade project for the CustTable table is that the table is not included in the upgrade project since there are no conflicts to resolve. In Microsoft Dynamics AX, CustTable has five fields, four in the SYS layer and one in the USR layer.

Scenario 2: Upgrading the VendTable form

As in the first scenario, Microsoft Dynamics AX has been installed as an upgrade to an existing Microsoft Dynamics AX 3.0 installation.

• The VendTable form exists in the SYS layer.
  In the SYS layer, the VendTable form has an additional button Y, added in the new version.

• The VendTable form also exists in the USR layer, where it has an additional button X.
  The VendTable form also exists in the USR layer, where it has an additional button X. The new and the old versions are identical.

As explained above, the Create upgrade project algorithm will be applied to the VendTable form as a whole. This results in the form being added to the upgrade project.

There is a potential conflict in the form because it has been changed in two layers. The form is added to the upgrade project and the conflict must be examined and resolved manually.

A variant on the form scenario

A variant on the form scenario occurs when a "hot fix" for Microsoft Dynamics AX 3.0 (a fix sent quickly for an issue that is causing a major problem) has been applied. When the .xpo file containing the hot fix was imported, the form was added to the USR layer. With the release of Microsoft Dynamics AX 2009, the hot fix has been implemented and is part of the standard application.

• Form A exists in the SYS layer.
  Form A exists in the SYS layer, in a new version as compared to the old SYS-layer version.

• Form A exists in the USR layer in a modified version.
  Form A exists in the USR layer in a modified version.

The following graphic shows the decision tree when implementing a hot fix.

Because form A is identical in the new SYS layer and the new USR layer, form A in the USR layer is obsolete and is deleted.