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 of these steps fail, the merge will be discontinued.
There are two options for merging:
-
Existing <- New
-
New <- Existing
Existing <- New
Using Existing <- New, the following items from the existing
object are always used:
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 exists in the old object, but not in the new. The
field will be left as it was.
-
The field exists in the new object, but not in the old. The
field will be added.
-
The field exists in both objects. If the properties are
different in the new object, these new properties will be used.
This can lead to problems that have to be resolved manually.
Consider, for example, 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.
New <- Existing
Using the New <- Existing option reverses the scenario.
The following items from the new object are always used:
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
