Code discrepancies in different environment

anunaya.mund

Member
So we have weird issue going on and I would really appreciate any advice I can get here.

Here are the Bullet points.

1. When we did a comparison in the c code between PD and PY, we found some mismatches,some objects were missing and some objects had code mismatches

2. We ignore objects in development or part of ongoing ESUs.

3. Even now, we were left with about a few missing objects and a few code mismatches, these code mismatches, were to do with SAR codes available in PY object source but missing in the PD objects's code.

4. So when I searched for those perticular SARs and related ESUs, weirdly in ESU logs it showed that the ESUs were applied success fully to all environments but somehow the SARs codes are missing in afew object, We verified omw loggings to see if any manual changes were made buit no luck.

5. So we dont know how this happened but we have this issue. Note- We used Beyond Compare to do the Dep server pathcode\source folder compare for this. So that showed us the n* and b* object differences but there must be other object types with similar issues.

6. So just re applying the ESU with forcemerging the objects might not be a good idea, as we dont what other objects from that ESu is affected.

7. Force merging all objects is also not feasible as the ESUs are fairly large and too many objects are there.

So any idea how we can fix this? get all obj. in sync? The reason for this is so that we can have reliable testing in PY.

We can do a full env. refresh including central objects from PD to PY, but thats another big no, no as it will make all our ESU etc applied logs and informations invalid.

So I am hoping I can get some directions from the JDE Gurus here... :)

Thank you.

Anu
 
Get all objects into an OMW project that you know have a discrepancy, check out/in - and test thoroughly in PY. Make a .PAR file from the PD objects to back them all up (just in case) Then promote to PD and deploy.

Its not uncommon to see customers have some discrepancies between DV, PY and PD. Over time, its almost impossible to keep everything in sync. So occasionally you have to run these types of test. You might want to consider doing this at the same time as a baseline ESU implementation (or just beforehand) so that you don't have to test everything twice. Just a thought.
 
Thanks Jon. The trouble is I can only know of the n* and B* objects that are different by doing their code compare using beyond compare. There might be other objects types with difference but dont know how to find them.

Also since PD is working fine, maybe copying the objects back to PY is a better idea??
 
You mentioned that the ESU's were applied fine. You deduced this from the ESU history? Take a look at the Spec merge PDF's for the objects that you find discrepancy. There is a good chance that there could be an error on those pdf's. I have faced these a couple of times, mainly with spec records. Now before making a code move, you need to ascertain whether the code in PD is current or if the code in the lower environment is current and then make a call based on this.
 
maybe copying the objects back to PY is a better idea??
Yes. Absolutely. Copying PD down to PY is always the right way if you get into this kind of position. However, I would do this on an object-by-object basis using OMW. Do not be tempted to perform a full PD to PY object refresh - as if you're having to perform SOX or some other type of audit, you might have issues.
 
Back
Top