Compare local update sets
-
- UpdatedFeb 1, 2024
- 5 minutes to read
- Washington DC
- Building applications
Administrators can preview local and remote (retrieved) update sets and compare the sets with one another to resolve conflicting changes.
About this task
Compare local update sets to identify collisions and ensure that the proper changes are being committed. Resolve all conflicts before moving an update set between instances.
Procedure
Update set collision resolution
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_id
s 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_user_group | name |
sys_wizard | name |
How customer update record names affect collisions
- 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.
- sys_dictionary
- sys_documentation
- sys_choice_set
- sys_ui_list
- sys_ui_related_list
The resulting identical record name in each instance helps the system to identify collisions even if the records have different sys_ids.
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".
Preventing duplicate records
- 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.