Restoring UBE

I just began working with a new company (2 weeks) and am still in the process of learning their system settings, structure, processes, etc. I am supporting their new implementation of JDE 9.0. I have been interfacing with the consulting firm that conducted the implementation. On the "issues" list I was given last week were about 35 items that they have been dealing with for quite a while, up to 8 months for some. One of the low hanging items was a change in the data selection of a BV.When I first attempted to mod the ver in OMW I realized that the only Obj Ver in DV was XX0004 while in PD/PY the only versions were XX0002 & XX0003. I contaced the consultants and was told that the DV Obj Ver were deleted about 6 months prior. I asked that the ones in PD be copied down to DV. this was done and I added the BaseObj & Ver to my DV project made the mod to the data selection and checked them all back in. The CNC consultant then promoted the proj up to PY. I tested the BV with the users and they were extremely happy that the "bad" data selection criteria was gone. The CNC then promoted the mod up to PD. The next morning I get a call from the users that the report format is completely diff. Upon examination i saw that the BV output was not the expected custom format but appeared to be the standard template format. The CNC had done a complete package build (EOM Process) the day prior to the project being implemented. Is there a way for the specific UBE (Base and Versions) to be restored?

Deploy last PD Full to a a developer client and t.hat can be your starting point

(db)

If you have a DV save location, you can restore your central objects from an old copy into the DV Save location (after you save off the original), then you can compare specs from DV to DEVSAVE and get the code changes. Afterward you can restore the Saved DEVSAVE and you're back in business.

James,

There's a lot of 'tricks' that us old geezers do (gregg thought I was going to say something else)....

As I suggested before - you could snag the last PD Full (or most-recent package to PD that contained the Objects) and apply that to your local machine. Once applied to the local machine... try the following (it has worked for me in the past)...

Steps to restore an Object:

** - before continuing, Check In and SAVE all existing Development on your machine
1 - Check out the Required Objects in DV (yes, this is important)
2 - Grab the PD Full that contains "The Last Known Good"
3 - Reboot your PC
4 - Rename your DVXXX folder to DVBACK
5 - Rename your PDXXX folder to DVXXX
6 - Log into E1
7 - Do an ER Compare - and see if you, now, have the "Last Known Good"
8 - If you have the Last Known Good - you can either Check it in, Export to Zip, Save to Save or.... At this point - You should be ok.
9 - After Checking-In, Saving, Exporting or 'whatever' - REBOOT
10 - Rename the former PDXXX from DVXXX back to PDXXX
11 - Rename your DVBACK to DVXXX
12 - Log Into E1 and make sure that everything is working
13 - Go to Collaborate - and find all the JDEList folks that are Presenting Sessions and introduce yourself!

If all this works as planned - you have completed another 13 step program - and you should be able to re-tweak the objects and re-promote 'normally'.

(db)

[ QUOTE ]

4 - Rename your DVXXX folder to DVBACK
5 - Rename your PDXXX folder to DVXXX


[/ QUOTE ]

That won't work, of course, with 8.12 or 9.0

You'll have to also rename the local specification database - depending on whether you have SSE or Oracle. This makes things a lot harder - though its not completely impossible.

Another way might be to deploy the object and then "save" the object using OMW export, then "restore" the object. I'm not 100% sure that will work since I think the "export" takes from central objects, not the local machine specifications.

Anyway, since you're really only talking about a version - the best thing is to just deploy the fat client, then use the RDA and version design aid to get screen dumps of all the correct information you need, then re-create the version in development and promote it back up. That might just be the fastest method unless you really, really know how to rename objects in your SSE !

Jon,

Does the rename hack stop at 8.11 (I recently tweaked it on an 8.10 -that's why it was fresh) or is it a tools related change (I can't recall when / how XML specs put the chill in our water of fun.

Alas - Jon did place the penny on the easiest solution:

Take the Production Package with the "Last Known Good"
Have your CNC configure PRODUCTION to allow Saving to the Save Location (or, simply Export the Specs using Save to Par).
Then, in DV, Do a Restore from the Save Location or the .Par you saved as an export.

Thanks for the mental refresher - that rule change was, only, four years ago?

(db)

[ QUOTE ]

Does the rename hack stop at 8.11 (I recently tweaked it on an 8.10 -that's why it was fresh) or is it a tools related change (I can't recall when / how XML specs put the chill in our water of fun.

[/ QUOTE ]

It stopped with 8.11 or so I think. Not 100% sure when, but the specs get saved with the package name as part of the object path - so in effect, if you rename the pathcode locally from PDxxxx to DVxxxx, your environment specifications will point you to your latest DVxxxx package specs DB - and therefore not the PDxxxx package specs DB that you need to actually get the object out of !

the .par export/import is probably the easiest method. Developers should ideally use the .par export as often as possible to create "snapshots" of their code - just in case things like this occur, then the developer can just re-import the code back into E1 again ! Save Locations can help to some degree, but eventually it just gets over-written ! You can use the .par export as a true version control system (or, of course, use Boomerang !)