Options for Merging Objects

The following sequence of events shows when objects are merged:

The old object is decompiled.
The new object is decompiled.
The objects are merged.
The resulting object is compiled.

If any one of these steps fail, the merge will be discontinued.

There are two options for merging:

Existing <- New

When you use Existing <- New, the following items from the existing object are always used:

Table properties.
Local C/AL functions on the table, including local variables.
Global variables.

The following items are merged into the existing object from the new object:
New fields.
Field properties that are different in the objects.
Trigger code on field level, including local variables.

Fields are merged based on the field number. The following scenarios are possible:
The field is located in the old object, but not in the new. The field will remain as it was.
The field is located in the new object, but not in the old. The field will be added.
The field is located in both objects. If the properties are different in the new object, these new properties will be used.

This could lead to problems that have to be resolved manually. For example, consider a new object that differs from an old object by introducing code in a field trigger and this code uses a global variable that is not in the old object. The merge will fail because the global variables are taken from the old object, and the merged object needs the global variable in order to compile.

A workaround would be to declare the global variable in the old object before merging the objects.

When you use New <- Existing option, this reverses the scenario.

The following items from the new object are always used:

Table properties.
Local C/AL functions on the table, including local variables.
Global variables.

The following items are merged into the new object from the existing object:
New fields.
Field properties that are different in the objects.
Trigger code on field level, including local variables.