SQL to identify modified/copied objects in E1

johndanter

johndanter

Legendary Poster
Hi guys,

I'm sure we've all wanted this at one point but I can't find it in a search here...

Does anyone have any SQL commands that read over the OMW F98 tables to list out the modified objects in E1.

Even better, is there a way identify cloned 55 objects to say where the original object came from?

Many thanks

John
 
The first one is a little complex, but the answer can be found searching here in the forums. Basically, you search on SIMGRMOD in F9860.

The second one, you can join F98210, F98211 on logkey, where the log is successful on the F98211, and where the object type is not a version (unless you want all of that). Then, join each of those tables to the F9860 to get the system code, and search where the f98210(lhomwobjid) is not in your custom system codes and where your f98211(ldomwldata) is on action type 06 (lhomwac). I know for sure this works in Xe/8.0/8.x, not 100% certain about 9.
 
Legend, thank you
smile.gif
 
JD,

A while back - I had to create a report that identified all object changes (to include copies and from what) as an ESU Validation.

I used the OMW Logging tables - to identify what was copied and to what.... Is that what you are looking for?

(db)
 
Board changed and that link is no longer valid, so you can search for SIMRGMOD (even googling SIMRMOD+JDElist will work)
 
Last edited:
Mo,

The only way you are going to get that type of information, is through the OMW Logging Files.

Key Thoughts:
- 02 Status means something was checked in. If an object has EVER been Checked In, it becomes Suspect for a Modification
- 06 Status means something has been copied.
* Log Detail 135H / 135J identifies if the copy attempt was made and if it was successful

Outside of logging - I am unaware of a way to accurately track customizations

Note: Please do not Clear OMW Logging, Auditors will burn you alive! =D

(db)
 
I agree with Daniel. When we did our upgrade for Xe to 9.0 the status gave us more false positives than actual, modified pristine objects. I had to create a UBE to basically parse the OMW logs to look for "evidence" that it was in fact a modified pristine object to narrow the list. Even then we had to manually verify the culled list.

Since then I keep my own list of modified pristine objects (in our SharePoint site). There is the chance that we might miss something but this has really been useful. Using MS Access connected to the SP list I can quickly cross check an ESU to identify where retrofits will be needed.
 
I wrote a UBE to do this too. I'll dig out the ER if anyone wants it.

Quite useful as I also list the OMW project and env dates the changed objects were promoted in
I did the same for cloned objects although I'm struggling to find a link with the BSFNs
 
I agree with Daniel. When we did our upgrade for Xe to 9.0 the status gave us more false positives than actual, modified pristine objects. I had to create a UBE to basically parse the OMW logs to look for "evidence" that it was in fact a modified pristine object to narrow the list. Even then we had to manually verify the culled list.

One way to weed out the false-positives, is to also check to see if an object is promoted (and to which environments).

If an object was checked-in, but never promoted - it shouldn't be a modified objects suspect, anymore. Now, if it was modified, copied and the copy promoted - well, that's the Development Cycle working for you.

As a rule, I don't check-out an object - Until AFTER I have started development on it. There's several SAVE Locations, and when I know that the customer has finally figured out what they want (lots of show/tell) - then I check-out and restore from my in-development object.

Never 'Check-In' something that didn't get changed - that's what the Drop Token option is for!

(db)
 
Last edited:
One way to weed out the false-positives, is to also check to see if an object is promoted (and to which environments).
(db)

Bingo! :)
This is exactly what I am doing. Seeing if something has been changed, checked in AND promoted. Even if just to PY. If all 3 I spit it out in the report
 
If an object was checked-in, but never promoted - it shouldn't be a modified objects suspect, anymore.
(db)

Would not have worked for us. For whatever reason our CNC team checked out/in a ton of pristine objects that had no modifications and promoted all the way to PD back in our Xe days.
 
Would not have worked for us. For whatever reason our CNC team checked out/in a ton of pristine objects that had no modifications and promoted all the way to PD back in our Xe days.


UGH! Them dastardly CNC Folk! I hear and experience your pain!

(db)
 
I guess I should have worded that differently. "..for whatever reason our CNC team was required to check out/in..."
 
I guess I should have worded that differently. "..for whatever reason our CNC team was required to check out/in..."

Our CNC here have been doing that too!!!
When questioned it was due to fact objects were 'in' the project but did not have the token. So a few trainees decided they should GET the token to promote :)

I since changed my changed object UBE to show complete SDLCs (up to PD) or just partial (DV or up to PY only etc)
 
If i recall correctly there is also a Standard object to list the modified objects. I remember i had to modify it to get the desired results. This can give you a quick start instead of developing it from scratch. As Den said it also gives you the movements of objects and projects that were involved so it becomes easy to identify if objects was modified years ago and never made it further.

Will post UBE Object name if i can find it in my archive.

Chan
 
Back
Top