ESU Merge vs replacing objects


Active Member
I have to loaded large ESU for payroll, several of my applications in payroll are slightly modified (time entry etc).

I installed the ESU .exe on my Dep server, logged into JDEPLAN and updated my Dev enviroment. Built and installed a full package and now in Dev all custom mods are gone.

From the Dep server if I looked at Merge Specs (p98401) from the DV, PY, PD, or DEP7334 I see all my modded programs correctly marked as "C" changed with spec merge set to "1".

If I log into JDEPLAN and look at P98401 I don't see any of my programs marked as "C" with merge code "1" set.

JDEPLAN has the object lib ODBC pointed to a local MDB file. DEV/DEP/PY/PD are all pointed at my SQL server, hence the differences.

I've RTF esu manual twice, and it's specific about running the ESU workbench from JDEPLAN.

So is my configuration mucked up and JDEPLAN should point at my SQL box for Object Lib so it can see the correct merge specs? I did run the backup during my ESU install so I can roll that back (and I have sql and dep backups worst case).

Just trying to figure out if I missed a step during the ESU or if the consultant that installed my dep server mucked up something during the install.


[email protected]@x

Well Known Member
The idea behind ESUs is to fix base code; ultimately replacing the bad objects with new ones from the ESU. The process doesn't care if the bad object was customized at all, it will overwrite the object.

With that said, if one of the "bad" objects has been customized, the new object from the ESU must be retrofited by a developer. Alot of companies will create a DEVSAVE database so Developers can save code before an ESU is installed. After the installation has occured, the developers then retrofits the new code installed by the ESU, while using the code in the DEVSAVE as a template.

Not all is lost though, you still have good working code in Production; at least I hope you do. A developer can use the code from Production as a template to retrofit the objects installed by the ESU.


Legendary Poster
ESU's will overwrite your existing objects - you're not trying to attempt an upgrade, you're trying to replace a bad object with a good one. You will need to retrofit - and your code should be in your other environments.

I have a whitepaper that discusses "best practices" (in my opinion of course) on how to implement ESU's to ensure that production isn't affected. For example, you probably are unaware that your data dictionary was modified already - IN PRODUCTION (since data dictionary is shared across all environments). My whitepaper explains all of these items. Get it from my website !