Why update sets committing older updates instead of latest updates on a file? - Support and Troubleshooting

Why update sets committing older updates instead of latest updates on a file? Issue  Overview When you move the customizations from source instance to target instance, at times, after commit, you may observe that update on a particular file is not what you have expected. You may observe that older updates are applied instead of latest updates.This article will brief on this specific scenario.

Possible scenarios Following are the 2 possible scenarios, why a latest update didn't applied while committing an update set,

Scenario 1:

You have retrieved the remote update set from source to target instance, then later took fews day to review before committing it. Meanwhile, you have done changes to the files at the source instance.

The remote update set will not have continuous live connection with the source instance until it is committed. The connection exists between the source and target instance only to retrieve the committed update sets.

When you wanted to get latest changes from source instance which was done after previewing the update set on the target instance, you might need to complete the update set in source instance and then retrieve the update set again on target instance.

Scenario 2:

You have more than one sys_update_xml for same file in same update set. Ideally, system never creates a sys_update_xml entry for same file in same update set for more than one time. There should be only one entry in sys_update_xml per update set per file.

User could manipulate the sys_update_xml for the specific file and hence it can ended up with more than one entries. When you have more than one entry we can not guarantee which one would be committed first, second, etc, system will decide it automatically.

As per document (Section: Working with update sets), updating the "updateset" field on sys_update_xml record is not recommended.

Copied below information from documentation for quick reference:

Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:

Switch to the desired update set. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field. Save the record. Back out the change just performed, and then save the record again. This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set. If you have more than one sys_update_xml entry for a file in a specific update set, you need to review all the entries and keep the only entry which has all the required updates and get rid of the other entries, so that you will not have any surprise after committing the update to target instance.

Additional Information Update set use

Update set transfers