HI Paul,
By chance can you use dbms_utility.compile_Schema after recompiling? Are you using it already? I know it doesn't answer your quesiton but this package is suppossed to follow the dependencies, no matter how odd they are (what you are describing below is pretty weird).
HTH
Lisa Koivu
Database Bored Administrator
Ft. Lauderdale, FL, USA
-----Original Message-----
From: Troiano, Paul (CAP, GEFA) [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, June 28, 2001 2:56 PM
To: Multiple recipients of list ORACLE-L
Subject: Invalid packages not being recompiled by Oracle
We have one package A that refers to package B. If package B's body and
specification are both recompiled by user 1, package A is correctly marked
as invalid. Another user, user 2, then attempts to execute package A and
gets the following error stack:
-- ORA-04068: existing state of packages has been discarded
-- ORA-04061: existing state of package "B" has been invalidated
-- ORA-04065: not executed, altered or dropped package "B"
-- ORA-06508: PL/SQL: could not find program unit being called
-- ORA-06512: at "B", line n ORA-06512: at line 2
User 2 then issues the statement 'alter package A compile;' It compiles
successfully and user 2 can now execute the package.
Why does Oracle not automatically recompile package A as it should? Since
user 2 was able to recompile the package in its existing state, Oracle
should not have failed at doing so. User 2's session instantiation of
package A (as well as all of their other instantiated packages) should have
been lost when package A was invalidated.
I understand that two possible options are: (1) Flush the shared pool after
recompiling; and (2) Manually recompile all dependent packages (such as A).
The first seems like overkill and will cause performance issues. The second,
with many dependencies involved, is not an option.
We need to consistently be able to recompile a package that other packages
are dependent upon without a user recieving the above error stack in
addition to not impacting performance or without having to recompile all the
dependent packages.
Thanks in advance,
- Paul
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Troiano, Paul (CAP, GEFA)
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
