Another important phase of PL/SQL compilation and execution is the checking of program dependencies, defined as follows. A dependency (in PL/SQL) is a usage relationship between a program and some Oracle object outside the program. Server-based PL/SQL programs can have dependencies on tables, views, types, procedures, functions, sequences, or package specifications, but not on package bodies or type bodies. Client-based PL/SQL programs can have additional dependencies on items such as form fields that exist only in the client-side module.
Oracle’s basic dependency objective for PL/SQL is, loosely speaking:
Do not allow a program to run 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.
If you’re working with server-side PL/SQL programs, you can use the server’s data dictionary to explore usage relationships in quite a bit of detail.
Here’s a simple illustration of this rule in action, using the data dictionary to give us eyes into the database. Let’s say that I have a package named bookworm on the server. In this package is a function that selects from the books table. If I create the ...