JD16881 installation

OliverHH

OliverHH

Member
Hi List !

We try currently to install ESU JD16881 to our DV environment. I log into JDE as user JDE, JDE-Plan environment and can see the downloaded ESU.
When I try to install it to the DV7333 pathcode with "unattended workbench" and "backup" checked, the process hangs during backing up the BSFN data.

I need the backup because i have to uninstall the ESU again. I just need some code included in the specs...

Any ideas whats going wrong (with me or the program :) ) ?

Oliver
 
How many objects are in the ESU? What is the latest planenr ESU you have installed?
 
This ESU has too many objects, it took me approx. 3 hours to apply to one environment. The first time I applied this I thought it hanged but it did finished successfully.
 
Oliver,

yes, I just applied to my JD7333 (Pristine) path with Backup UNCHECKED for the same reason as you - to find a fix embedded in this monster ESU. It still took about 3 hours to run . . .

In my opinion this is the best use of the Pristine path. I can now look for the specific code change using ER compare and other tools but not have to worry about uninstalling.

Cheers,
 
Oliver,

This is a large esu and may take a while, but there are couple things you can check:

1 - On your deployment server, sign out of oneworld. Look in the planner/data directory and make sure there are no access lock files. If there are, delete them. It's a good bet you've killed a oneworld session and the access db didn't close properly.
2 - In planner/data, for both jdeb7.mdb and jdeplan.mdb...open the database and run tools|database utilities| compact... This will take a few minutes, but will clean up the database and ensure it's not reaching its size limit of 1 gig. If you are running the update as described and it is not coming back with any .pdf reports showing parts complete, this may help you. Just compact the databases and rerun the update.
3 - Run the update to just one environment at a time.
4 - Reboot the deployment server before starting to apply the update.
5 - Make sure you give it enough time before you start to panic. The "initial" run may take one to two hours before the actual merges and updates begin.
 
Oliver,

This is a large esu and may take a while, but there are couple things you can check:

1 - On your deployment server, sign out of oneworld. Look in the planner/data directory and make sure there are no access lock files. If there are, delete them. It's a good bet you've killed a oneworld session and the access db didn't close properly.
2 - In planner/data, for both jdeb7.mdb and jdeplan.mdb...open the database and run tools|database utilities| compact... This will take a few minutes, but will clean up the database and ensure it's not reaching its size limit of 1 gig. If you are running the update as described and it is not coming back with any .pdf reports showing parts complete, this may help you. Just compact the databases and rerun the update.
3 - Run the update to just one environment at a time.
4 - Reboot the deployment server before starting to apply the update.
5 - Make sure you give it enough time before you start to panic. The "initial" run may take one to two hours before the actual merges and updates begin.
 
Oliver,

This is a large esu and may take a while, but there are couple things you can check:

1 - On your deployment server, sign out of oneworld. Look in the planner/data directory and make sure there are no access lock files. If there are, delete them. It's a good bet you've killed a oneworld session and the access db didn't close properly.
2 - In planner/data, for both jdeb7.mdb and jdeplan.mdb...open the database and run tools|database utilities| compact... This will take a few minutes, but will clean up the database and ensure it's not reaching its size limit of 1 gig. If you are running the update as described and it is not coming back with any .pdf reports showing parts complete, this may help you. Just compact the databases and rerun the update.
3 - Run the update to just one environment at a time.
4 - Reboot the deployment server before starting to apply the update.
5 - Make sure you give it enough time before you start to panic. The "initial" run may take one to two hours before the actual merges and updates begin.

good luck.
 
Here's another option you can try. I've used this approach many, many times to retrieve a single object, look at ER, etc.

1. Determine a path code that is not in use and you can have exclusive use of for awhile. ( I typically use JD7333 for this )

2. Rename the SPEC folder inside of the JD7333 folder (or whatever environment you're using).

3. Extract the SPEC folder from the ESU zip file to the JD7333 folder.

4. Using P9860 you can selectively checkout objects from the specified environment.

Now you have the object in spec form on your local workstation. You can check this into a different environment, view the ER, etc.

Be sure to move the original SPEC folder back to maintain integrity.

Obviously...this would be an unsupported approach from JDE. BE CAREFUL. I've been in the same situation as most of you where I've need a specific SAR but cannot justify applying a 200+ MB ESU.

I'm looking forward to the baseline ESU.

- Scott
 
Back
Top