A collision is an update that has a newer local update.
The platform detects collisions by comparing the values in the Name and
Updated fields of the Customer Update record from each update set. If the name
matches but there are different update date values, then there is a collision.
When a customer update is moved from one instance to another, it may be re-written to match the
target instance. The re-write can involve changing the update name of the customer update and one
or more sys_ids within the update. The re-writes are done when the record or the
reference field is for a table that uses a coalesce strategy. This ensures that the customer
update will be applied to the correct record. For example, if the sys_dictionary
record for tablename.fieldname has sys_id
123456789 on instance A and sys_id
987654321 on instance B, when a customer update that refers to that record is
retrieved from instance A and recorded in the sys_update_xml table on instance B, references to
123456789 are updated to read 987654321.
Coalesce Strategies
Update sets can detect collisions between identical records that you independently create on
separate instances. To detect such collisions, the record must have a coalesce strategy based on
coalescing columns. Because collision detection depends on uniqueness of tables, the tables must
be unique when the coalescing columns are combined. Records that are not listed here will not
collide if the same record is created separately on different instances.
| Type |
Coalescing Columns |
| sys_db_object |
name |
| sys_dictionary |
name, element |
| sys_choice_set |
name, element, language |
| sys_documentation |
name, element, language |
| sys_properties |
name |
| sys_report_chart_color |
name, element, value |
| sys_ui_form |
name, view, sys_domain |
| sys_ui_message |
documentkey, language |
| sys_ui_list |
name, view, sys_domain, element, relationship, parent |
| sys_ui_section |
name, view, caption, sys_domain |
| sys_ui_related_list |
name, view, related_list, sys_domain |
| sys_ui_view |
name |
| sys_user_role |
name |
| sys_wizard |
name |
How Customer Update record names affect collisions
To understand coalescing, it helps to understand how records that do not coalesce work:
For most record types, when a Customer Update is moved to a new instance, the system does not
detect collisions for the following reason:
When you create a record, it receives a unique Sys ID. For most record types, the Sys ID
becomes part of the Customer Update record name. For example:
sysevent_email_template_9e1998c078b71100a92ecacd80df1d39
Creating an identical record in the same table on another instance produces a Customer Update
record name with a different Sys ID, for example:
sysevent_email_template_10b958c8653311005840134572f8e020
As a result, even though the records might be otherwise identical, the records have different
names so the system does not detect the collision.
Coalescing records, in contrast, use the following approach to naming records and determining
collisions: The following Customer Update record types use some or all of their coalescing
columns instead of the Sys ID in their names. The resulting identical record name in each
instance helps the system to identify collisions even if the records have different Sys IDs.
sys_dictionary
sys_documentation
sys_choice_set
sys_ui_list
sys_ui_related_list
To prevent creating duplicate records with update sets:
- Transfer data with update sets rather than recreating it on separate instances to ensure
the records have the same Sys ID.
- Export and import records as XML files to ensure the records have the same Sys ID. See Export and import XML files.
- Enable a unique index for the table from the system dictionary. See Table administration.
Note: The default records included in the baseline system will always have the same
Sys ID because the instance imports the records as XML files during instance
provisioning.
