ORA-04062 During Oracle Migration 7.3 (UNIX) to 8 (W2K)

[ROPMax]

We're migrating from Oracle 7.3 on UNIX to 8.0 on the LAN. We are stymied by the ORA-04062 error coming from a 3rd party system created in Developer 2000. We've read many posts on several websites on how to solve. We understand the error is the result of either the datestamp or the signature changing on certain PL/SQL objects stored in Oracle.

The standard fix - recompile the caller - won't work in this case as we do not have access to the source code of the caller (3rd party proprietary code).

Our 2nd attempt at a fix - resetting all the time stamps on the Oracle8 server to match those under 7.3 (table SYS.OBJ#) - didn't work either (presumably because Developer 2000 issues an ALTER SESSION command so that signatures are compared instead of timestamps?).

Our 3rd attempt at a fix involved putting "REMOTE_DEPENDENCIES_MODE=SIGNATURE" in the init.ora file then restarting Oracle. I even went so far as to revoke the "ALTER SESSION" and "ALTER SYSTEM" grants on my Oracle ID just to make sure the SIGNATURE setting wasn't being overridden. No luck. Not even with a couple server reboots thrown in for good measure. Not even after recompiling PL/SQL stored in Oracle.

Our 3rd party developer is (so far) unresponsive but I expect fairly soon they will jump at the chance to charge us big $$$ for a system overhaul (which is one reason why we're not going to Oracle 10 right away). But there has to be something we can do at our end to make our 3rd party Developer 2000 system run under Oracle8. In fact, I'm amazed that the SIGNATURE thing didn't work.

If it makes any difference, all our Oracle packages, procedures, etc. are "wrapped" by our 3rd party developer - proprietary code and all that. We can still compile those - in fact, recompiling them is a required part of the migration. But we can't touch the Developer 2000 Forms programs. Also, if it helps, the ORA-04062 error is generally followed by the ORA-04068 error which seems to have a similar root cause.

Any suggestions would be welcome. We are in a little bit of a hurry - starting to run out of disk space on our aging UNIX boxes.

[ROPMax]

I understand this scenario would be extremely difficult for anyone to setup and test an idea - especially since so few companies have the CIRIS Policy Management System (by Infoel). I would be happy to try any untested suggestion, half-baked idea, slim-chance thought, anything.

Our 3rd party developer has now weighed in. Claims Oracle 8.1.7 works fine with their system without recompiling any Developer 2000 programs. So we are left to assume that Oracle 8.0.4 has a bug related to the REMOTE_DEPENDENCIES_MODE=SIGNATURE startup parameter? I have my doubts. I still think that Oracle 8.0.4 should work and we have overlooked something somewhere. In any case we will find out in a few days when installation CD's arrive (assuming we can still get them).

My latest failed brainstorm - I did a search for objects whose names (and hence signatures) had changed due to uppercase translation during the migration. Found only 4 indexes (in production) and 2 synonyms (in development) where this had happened. So no help there.

[tamilselvan]

1. I assume you still have vendor support. If so, did you contact the vendor?
2. Oracle 7 and 8 are 15 years old technology. Do you have oracle support for these releases?

[ROPMax]

1. I assume you still have vendor support. If so, did you contact the vendor?
2. Oracle 7 and 8 are 15 years old technology. Do you have oracle support for these releases?

Amazingly enough Oracle immediately sent me CD's for 8.1.7 - no questions asked. That would put me on exactly the same version which our 3rd party developer claims works fine for them. Should know in a day or so if it fixes anything.

I also obtained from our 3rd party developer their init.ora file which I compared to ours. Didn't see any significant differences but I made a couple tweaks anyway. (Gotta do something). Unfortunately the tweaks didn't help but I noticed that their compatibility parameter read 8.1.0, not 8.1.7. Maybe they're not running the version they say they are?

As far as Oracle actually SUPPORTING version 8 goes, I really doubt it. Especially since the only application failing is the CIRIS Policy Management system (3rd party). We have a variety of in-house applications in COBOL, Approach, Access, Business Objects and Cold Fusion all of which work fine with the new Oracle servers. Possibly we could claim it's a Developer 2000 problem (which might actually be true) and get some support that way.

[marist89]

ugh, that sucks. v8 AND Windoz.

[ROPMax]

The good folks at Oracle shipped me version 8.1.7 - no questions asked. I installed it and, much to my amazement, our 3rd party Policy Management system seems to work well with it.

I am still quite dumfounded as to why Oracle 8.0.4 would not support old Developer 2000 systems but 8.1.7 does. But I guess that no longer matters. I'm closing this thread. Thanks to all who may have read it, pondered it and/or contributed to it. And if anyone else is pondering a migration from 15-year-old technology to 14-year-old technology, I guess the lesson is to go for the latest release of whatever version you are targeting.

Or maybe a better lesson is to never get yourself in this type of situation in the first place?