We just got our 10.2.300.3 test environment set up on a brand new server. Our starting DB was our 10.0.700.4 end of month snapshot.
I’m importing our UI customizations from our 10.2.200.x test environment where I fixed the various issues like overlapping fields. I’ve get the error message of “There is a duplicate customization definition with the same primary keys” on 4 of 5 I’ve imported so far. Why?
If I click yes and overwrite - will it mess up any new features in from the .300 release?
Am I back to square one and fixing each UI from scratch (since we are ultimately planning our GoLive to go from 10.0.700.4 to 10.2.300)?
Did you rename your UI Customizations in your 10.2.200.x test environment? Or are they the same names as the ones found in your 10.0.700.4 database? If you did not rename them, then I would assume you would have the same UI Customization names in your 10.2.300.3 test environment and your import is just trying to overwrite those existing Customizations that came over in the snapshot. So I would assume it’s your choice that you could overwrite them but to play it safe, I think I would rename them in your 10.2.200.x test environment and then import them into your 10.2.300.3 test environment just to be able to look at them and make sure they look ok in a side-by-side comparison of the base 10.2.300 form versus your customization.
@ERPSysAdmin - Thanks. I kept the same name, since I didn’t want to have to re-do all the menu entries to point to a different customization.
If Customization / Personalization Maintenance uplifts the imported XML to add all the latest .300 fields during the import / verify process, then I think I’m OK checking Yes (overwrite). I’ll do a side by side compare against .200 and the .300 edu db to see if it missed anything. Thanks again.
I can’t say that the Customization / Personalization Maintenance uplifts the imported XML to add all the latest .300 fields during the verify process…I don’t think that’s necessarily the case. I think it just checks for problems in your C/P and verifies whether or not it is working properly. I would just be careful because sometimes your customization can overwrite new fields and sections that have been added to the base forms. So side-by-side comparison with the base form is always a good idea for major patch level increases I think. I don’t know that there is an easier way to do it…
EDIT: I wanted to mention that we try to change the color of our field labels so we know which ones are the customized ones and we can easily identify them when doing the comparison.
