With the release of Cumulative Update 7 (CU7) for Microsoft Dynamics AX 2012 R2, users upgrading from a previous Dynamics AX 2012 R2 version may experience compiler errors on a few forms which were not intentionally modified in the previous version. These compiler errors may appear on the following forms – SalesTable, SalesQuotationProjTable, and SalesQuotationTable. A few examples of the errors are given here for reference:

 These errors occur because of a combination of two items:

  1. New data sources were attached to the forms as part of the CU7 upgrade which places the data sources in the SYP layer
  2. A higher layer customization for the form already existed in the application code such as in the USR or VAR layer, specifically the Data Sources node within the form.

The compile errors occur because the new methods added with the CU7 upgrade expect the new data sources to exist, but because the Data Sources node exists in a higher layer, the compiler will not see or be able to use the new data sources. There are two scenarios that will be described to discuss how to address the compiler errors properly.

Scenario 1 – A valid customization was previously made in a higher layer to the form to add new functionality

This scenario should be familiar to all developers that have previously done code upgrades where changes made in the SYP layer have to be merged upwards into the higher layers where customizations were made. These changes to add the new data sources and make all needed script modifications can be moved individually, but the developer should evaluate if the Data Sources node should just be deleted from the higher layer and allow a newer version of it to be created where their changes could be remade.

Scenario 2 – The user never intentionally made a customization to the form, but a USR layer version of the form and Data Sources node exist in the AOT.

With Dynamics AX 2012 R2 RTM release and Cumulative Update 6 release, an issue with the X++ compiler created phantom Data Sources nodes on several objects within the AOT. The three forms listed above were common examples where the phantom Data Source nodes got created. There was no difference between the phantom USR layer information and the original code so it is possible that this scenario has gone unnoticed within the user’s system. An example of how this type of scenario might appear in the user’s AOT and Compare windows would look like this after CU7 has been installed:

 

The solution to fixing this scenario is to do the following actions:

  1. Have the developers responsible for the system validate that there should not be any changes to the Data Sources that were made previously – if changes were found, follow the steps in Scenario 1 above.
  2. If no customizations should exist, then log into the highest layer where the Data Sources phantom node appears. Go to the AOT and find the affected object and expand the tree so the Data Sources node can be selected.
  3. Right-click on the Data Sources node and choose Delete, and confirm that you want to remove the object. This will simply remove the current layer’s version of the Data Sources, not remove the objects from the core system code.
  4. After the Data Sources node has been deleted, right-click on the form name and choose to Compile. This should allow the compile to proceed with no errors.
  5. After making all these changes, running the process Generate Incremental CIL can be run to complete the process.

Changes were made with the CU7 compiler to prevent the phantom data sources from appearing again, but they cannot be removed automatically because there is no way to determine if a true customization was made.