We CNCs have 101 tasks to do every day. Some of them you WANT to do, and many are ones you HAVE to do. Generating an Impact Analysis is one of those tasks that is both. You should have to do it, AND you should want to do it. In the long run it will save you and your company lots of valuable time and reduce the risks associated with change.
What is package compression and why do you care if it is used? I spent my first 7 years as a consultant building packages for one particular client. I built packages for 3 environments two times per day. I discovered three issues in the area of package management: disk space, time, and keeping development clients up to date.
Repository History is created when you apply an ESU, check an object in, promote an object in OMW, etc. You can access the Repository to get information about all historical actions that have been taken affecting object specifications. For this example, after application of an ESU, errors were being received that indicated there was a problem with the structure of one of the JDE tables. The ESU was reapplied using Force Merge for this object, but the error remained. In order to verify that specs were updated by application of the ESU, P98780H was used to export objects and compare them.
So, way back last year (okay, just a few weeks ago), Chris wrote Part 1 of this blog, and promised a Part 2 with a 9.1 workaround for the same problem. To recap – a client wanted to grant access via Databrowser to just a few tables for a role. We knew we couldn’t use object level security, as that would completely limit that user in all of E1 to just those few tables. In the first part of this blog – I’ll pause here in case you want to go re-read – Chris talked about how to accomplish this in 9.2 with UDO View security. But there are still E1 customers on 9.1, so how could they accomplish something similar without the cool UDO features you get in 9.2?