what are the problems that generally occur in update sets
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-05-2017 10:57 PM
Hi everyone,
A)I marked one update set as complete and then changed it's state to in progress and then again marked it complete . It was capturing the recent updates successfully .Then Why do people caution us about this that do not open the Complete one.??
B) Also, need to know one thing if we did some customizations in Developement environment and then when we moved that changes to Test
they are getting blank after creating new Incident ....??? What can be the causes for the same ....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-07-2017 10:18 PM
Hi Gaurav,
I had accepted all the conflicts but later when I went I clicked on Create Incident to view my changes ... it was complete blank page
that was what suprised me .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-07-2017 11:02 PM
Hi Creativethinker,
Here goes some thoughts that hopefully are helpful:
a) as long as you have selected your update set, your changes should be recorded without issues within your update sets. There few elements within a platform that will not be automatically recorded within an update set, like: scheduled jobs, discoverable business services, homepages, among few others which are just exceptions to the rule.
b) make sure you properly review that the update set contains only the changes that it should contain. These shouldn't had more, neither should have less. A very common error is to record changes within the default update set when on reality the intent was to record these on the update set. Same happens the other way around, where an update set may contain unrelated changes to the ones intended with the update set. For your specific scenario around your incident. I do will recommend you review your update set and also review within the development environment the changes within the default update set around the day(s)/time(s) you were doing the intended changes in your update set.
c) another reason why you may be observing a different behavior in test than in dev could be because someone has altered the records directly within the Test environment. Within "software development" and "change management" good practices... that's about a capital sin.
d) the troubleshooting process to understand what's going on in your situation is to look into the versions of the specific records you're facing issue with. Validate the versions list within dev and then within test and understand what's missing. If you're unclear what object it's the one affected, you can choose to do any changes on it and then navigate to sys_update_xml.list (hit enter after you enter this in the navigation window) and sort it out by the most recent records. Your change should be in the top of the list and you should be able to see the affected table/record and then enable & see the versions related list of that record within dev and test to understand the differences.
Thanks,
Berny
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-07-2017 11:02 PM
I hope this helps!