Restore error when save object from TR 8.97.23 and restore to TR 8.98.49

When I saved the object from 8.97.23 fat client I got a .zip file and when I tried to restore 8.98.49 system promot for UBE_xxxxxxxx_60_99.par and got a Restore error.
--- From jde.log
6140/5868 WRK:Starting jdeCallObject Mon Oct 01 10:12:56.168000 OMWEntry.cpp575
OMWMethod : eRESTORE -- OMWExceptionError caught. Error : OMWManifest::readPARManifest - XMLC_loadParserFromFile(C:\DOCUME~1\SHULIK~1\LOCALS~1\Temp\OMWSAVE\02D9AAEF-3E95-4FCC-9F06-F58DEA2D6493\R5509000\manifest.xml) failed with error : 4

Questions:
1. Is that possible to save object (zip) from 8.97.23 and Restore to 8.98.49 (file format UBE_xxxxx_60_99 with .par file extension)?
2. Any other way to save/restore object? Beside recreate object is there any other 3rd party software to meet save/restore requirement? How about Boomerang software?

Thanks in advance to share.

8.12 Application, 8.98.49 TR, SQL 2008 R2

Boomerang will certainly work!

dunno about 8.97.23, but i've done it a few times recently between TRs 8.98.4.5 and 9.1.0.4, without any problems.

Shu,

I've never run into an issue Restoring an object saved on a different machine or release - so I'm interested in the issue.

Here's a couple things to consider, from my experiences (everyone else's may very).

- You have to have the template of the UBE Created, beforehand. Meaning, create the UBE, don't actually Develop it beyond what is required to check it in - then check it in.
- You don't have to rename the .par that you are going to import. Your destination object could be R559999 and you could import R668888 into that object.
- If you edit any of the XML - do not use Notepad. Notepad may save it in a file format that is disregarded by the Restore process. Use Notepad++ instead. HINT: You can use Notepad++ to Find/Replace a value within a folder tree - which is GREAT for replacing BSVWs (Just point it to the expanded SPEC folder in the .par and have some fun)

Remember - Oracle says we can't do a lot of things. If one of their employees got sick while exercising - they'd tell everyone that asked for a key to the exercise room, 'no'. However - those that persist in finding another place to exercise would, generally, live a long and happy life. "No" is not always the final answer, sometimes we just have to ask the question "How", instead.

(db)

[ QUOTE ]
You can use Notepad++ to Find/Replace a value within a folder tree - which is GREAT for replacing BSVWs

[/ QUOTE ]

Daniel, I recently tried to see how far one can go finding&replacing in xml files for a bunch of UBEs and Interactive Applications. I found out you can go far: bsvws, tables, data dictionary items, ER variable names, bsfn names, bsfn dstr member names, FI/FC/RV/RC-names, TVs: You can pretty much replace anything you want (Of course you need to create the replacement bsvws/tables/data dictionary items first if they don't exist yet). You can pretty much completely transfer/port an application without having to enter FDA/RDA once.

Attached is the zip file from 8.97.23. I do have shell created under 8.98.49 before restore.

Oracle response line answer - 'You cannot restore the par file into the newer zip. This is due to changes in the functionality' But 8.97.23 created .zip file and 8.98.49 is looking for .par file. Thanks for all of your input

SL922: I usually export&import a project (You need to create an (empty) project in the destination env. with the same name as the one you're going to export from the source env.). Upon importing (restoring) the project, the objects are imported to the dest. env.).

[ QUOTE ]
PS: Never had to create a UBE-template beforehand though.

[/ QUOTE ]

Researching further - it looks to be a limitation of older tools releases. In Oracle Doc #655700.1
[ QUOTE ]
There are some limitations in using this feature for Tools Releases 8.96* and 8.97*:
It does not save the following information to the ZIP file:
Object Librarian info (F9860, F9861, F9862, F9865, F983051)

[/ QUOTE ]

That said, in older tools - You can save to .par. If you attempt to import the 'project' into a system that doesn't already have the objects defined (as in above quoted tables) - the import 'may' fail. My experience has been, that creating the template of the object (enough to create the F98* entrees) resolves the import in older releases.

Oracle doc #ID 654394.1 - Notes that, "...Tools Release 8.98.0.3 or higher..." "A PAR file is similar to a zip file in that it contains compressed files and directories. Developers can use OMW to create PAR files for individual objects in order to easily transfer the object to another machine for testing or further development"

The same document states that Projects can be saved via Save/Restore - but the note does not specifically state Project Portability. My experience is that the Project has been portable (with a few undocumented tools exceptions)

Yes - I, too, am finding that there isn't much you "can't" find/replace in an XML.

(db)

Shu,

In the zip you provided, there is no F9860.xml, F9861.xml or manifest.xml. I'm assuming the older tools release did not provide them - thus the portability issue.

To confirm, you did create the shell of the R5509006, T5509000 and V550911M (and any other custom objects associated with the R5509006)?

I'm not sure if the OMW Tables can be inserted into the .par, and have it still be valid - might be a fun experiment. Might be a quick way to change properties of an object(Save, alter F9860 properties in the .par and restore)

Rambling - might have to try.

(db)

Hi, I was able to moved the object from TR 8.97.23 to TR 8.98.49 by renamed file name, repalced and added files. I will write detail instructions if anybody is interested. Thanks for all of your attention.

Hi SL922,

I have the same issue in 9.1.2.2 and 9.1.3.

have the instructions to repair this issue?

thank you very much