I did a trial USEM upgrade and fixed all scripts, then there was a clone over our sandbox.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago - last edited 5 hours ago
Hello!
I did a trial run of a VR to USEM upgrade in our sandbox instance.
I carefully reviewed/merged all upgrade script conflicts so that our customizations would still work.
All changes were saved in update sets, which I carefully saved.
Our sandbox was then recloned from our prod instance, and I need to do it again.
Also, I'll need to upgrade and then move the same update sets to our dev/stage and then prod instances in the future.
The problem is all of my update sets don't seem to work!
I've got 91 "This update will not result in any action because it is invalid" warnings.
And about 20 "Cannot commit Update Set 'UpdateSetName' because: Update scope id 'xxxxxxxxx' is different than update set scope id 'global'. Resolve the problem before committing."
And 1 "This update's payload is empty or is not properly formatted XML".
Any idea how I might speed up resolving all these issues? Are the "will not result in any action" warnings because the upgrade history log have different system ids so it's not setting them to "merged"? If so, I should just be able to ignore those, yes? And the actual updates to the actual scripts should still happen? Or do you think that some of the merged scripts themselves might be included in these, maybe because they have different sys_ids with the second USEM upgrade?
Any idea how to resolve the application issues? I had 6 different update sets in different applications, and I shouldn't have been able to ever save things unless they were in the right one!
Any other suggestions?
Otherwise, I'm grabbing the updated scripts straight from the XML and re-pasting/re-merging them all one at a time, and I'd love to have a faster option.
Much thanks!
Much thanks!
