Upgrade problems caused by field- or table Id conflicts

  • Article

When a field or table that is added by a partner or customer in a higher layer than SYS, for example VAR, is subsequently added by Microsoft in the SYS layer with the same, you see a conflict during the synchronization process and consequently an error is thrown.

One solution and the official solution in earlier versions has been to rename the field in the higher layer and then write an upgrade job to move the values from the old field to the new field. Moving the data of course prolongs the upgrade process.

In 4.0 a set of helpful methods have been added, allowing you to manipulate the SQLDICTIONARY table to realign the existing field and table definitions to the new SYS definitions. Doing that resolves the conflict and you don’t have to move any data around.

The methods you can use are the following static methods of the ReleaseUpdateDB class:

  • changeFieldId
  • changeFieldByName
  • changeTableId
  • changeTableByName

The code calling these methods must be added a pre-sync start job to the relevant ReleaseUpdateDB… class.

You can actually see a similar approach back in 3.0 SP3 (as I recall it) GLS/GLP layer where the Cost Accounting module is realigned to new table and field id's taken from 4.0.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm