Verifying that expected records are contained in the Update Set
Symptoms
- There are instance issues post commit
- Update Sets show as committed but have inconsistencies
- Not everything is updated after the update set completes
Cause
This issue can occur when an Update Set may be caused by a system error or warning, or unique key violation.
Resolution
Review the Update Set Preview for any errors, warnings, or collisions that may have been missed, or where unintended Skip actions were chosen.
If everything looks good in the preview, verify that the payload actually contains the updates that the customer is missing. If the updates are not in the payload, go to the Update Set source instance and review sys_update_xml.list for the missing records. If the updates are within the payload and have not been skipped, retrieve and review the Commit Logs:
- Locate and download the System Logs for the day that the Update Set was committed. You can do this by navigating to System Logs > Utilities > Log File Download.
- Once you have downloaded the System Log and opened it, use Find to search for lines that pertain to the name of the Update Set. Generally, the first lines you see are for the Update Set Preview, and following these are the Update Set Commit records. Review the commit records for anything out of the ordinary. This includes items such as: Warnings, Errors, Unique Key Violations, etc.
If the logs show records for Unique Key Violations and/or Duplicate Entries and the Disposition within the Update Set Preview shows Insert when it should show Update, verify that the person committing the Update Set has their Domain in their User ID set to global. Having any other Domain listed causes the Disposition within the Update Set preview to be incorrect, and sporadically causes updates to be Inserted instead of Updated on commit-generating Unique Key Violations.
When using Domain Support, if the selected domain is anything other than global in the Domain Picker, the Commit UI action is removed from within Update Sets.