Another very important phase of PL/SQL compilation and execution is the checking of program dependencies. A dependency (in PL/SQL) is a reference from a stored program to some database object outside that program. Server-based PL/SQL programs can have dependencies on tables, views, types, procedures, functions, sequences, synonyms, object types, package specifications, etc. Program units are not, however, dependent on package bodies or object type bodies; these are the “hidden” implementations.
Oracle’s basic dependency principle for PL/SQL is, loosely speaking:
Do not use the currently compiled version of a program if any of the objects on which it depends have changed since it was compiled.
The good news is that most dependency management happens automatically, from the tracking of dependencies to the recompilation required to keep everything synchronized. You can’t completely ignore this topic, though, and the following sections should help you understand how, when, and why you’ll need to intervene.
In Oracle Database 10g and earlier, these dependencies were tracked with a granularity of a program unit. So if a procedure was dependent upon a function within a package or a column within a table, the dependent unit was the package or the table. This granularity has been the standard from the dawn of PL/SQL—until recently.
Beginning with Oracle Database 11g, the granularity of dependency tracking has improved. Instead of tracking the dependency ...