Procedures

-A procedure is a subprogram that performs a specific

action.
-You write procedures using the syntax :-
PROCEDURE name [(parameter[, parameter, ...])] IS
[local declarations]
BEGIN
executable statements
[EXCEPTION
exception handlers]
END [name];

where :-
1)parameter stands for the following syntax:
parameter_name [IN | OUT | IN OUT] datatype [{:= |
DEFAULT} expr]
2)You cannot impose the NOT NULL constraint on a
parameter.
3)you cannot specify a constraint on the datatype. For
example, the following declaration of emp_id is illegal:
PROCEDURE ... (emp_id NUMBER(4)) IS -- illegal; should
be NUMBER
BEGIN ... END;
4)A procedure has two parts:

- the specification.

- the body.
5)The procedure specification :-
-begins with the keyword PROCEDURE .

- ends with the procedure name or a parameter list.

6)Parameter declarations are optional. Procedures that
take no parameters are written without parentheses.
7)The procedure body begins with the keyword IS and ends
with the keyword END followed by an optional procedure
name.
8) The procedure body has three parts:
1) a declarative part.
2) an executable part.
3) and an optional exception-handling part.
9)The declarative part contains:

- local declarations, which are placed between the

keywords IS and BEGIN.

- The keyword DECLARE, which introduces declarations

in an anonymous PL/SQL block, is not used.

- The executable part contains statements, which are

placed between the keywords BEGIN and EXCEPTION
(or END). At least one statement must appear in
the executable part of a procedure.

- The NULL statement meets this requirement.

- The exception-handling part contains exception

handlers, which are placed between the keywords
EXCEPTION and END.
EXMAPLE:
Consider the procedure raise_salary, which increases the
salary of an employee:
PROCEDURE raise_salary (emp_id INTEGER, increase REAL) IS
current_salary REAL;
salary_missing EXCEPTION;
BEGIN
SELECT sal INTO current_salary FROM emp
WHERE empno = emp_id;
IF current_salary IS NULL THEN
RAISE salary_missing;
ELSE
UPDATE emp SET sal = sal + increase
WHERE empno = emp_id;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN
INSERT INTO emp_audit VALUES (emp_id, 'No such
number');
WHEN salary_missing THEN
INSERT INTO emp_audit VALUES (emp_id, 'Salary is
null');
END raise_salary;
When called:
-this procedure accepts an employee number and
a salary increase amount.

- It uses the employee number to select the current

salary from the emp database table.
 - If the employee number is not found or if the
current salary is null, an exception is raised.
Otherwise, the salary is updated.
A procedure is called as a PL/SQL statement. For example,
you might call the procedure raise_salary as follows:
CALLING: raise_salary(emp_num, amount);

Stored Procedures and Functions

A stored procedure or function is a PL/SQL program unit
that:-
• has a name.
• can take parameters, and return values.
• is stored in the data dictionary.
• can be invoked by many users.
Note: The term stored procedure is sometimes used
generically in this Guide to cover both stored procedures
and stored functions.

Procedure Names
-Since a procedure is stored in the database, it must be
named:-
1- to distinguish it from other stored procedures.
2- to make it possible for applications to call it.
-Each publicly-visible procedure in a schema must have a
unique name.
- The name must be a legal PL/SQL identifier.

Note: If you plan to call a stored procedure using a stub

generated(what it means?) by SQL*Module, the stored
procedure name must also be a legal identifier in the
calling host 3GL language such as Ada or C.
-Procedure and function names that are part of packages
can be overloaded. That is, you can use the same name for
different subprograms as long as their formal parameters
differ in number, order, or datatype family. See the
PL/SQL User's Guide and Reference for more information
about subprogram name overloading.
Procedure Parameters
-Stored procedures and functions can take parameters.
The following example shows a stored procedure that is
similar to the anonymous block :
PROCEDURE get_emp_names (dept_num IN NUMBER) IS
emp_name VARCHAR2(10);
CURSOR c1 (depno NUMBER) IS
SELECT ename FROM emp
WHERE deptno = depno;

BEGIN
OPEN c1(dept_num);
LOOP
FETCH c1 INTO emp_name;
EXIT WHEN c1%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(emp_name);
END LOOP;
CLOSE c1;
END;
In the stored procedure example, the department number is
an input parameter, which is used when the parameterized
cursor C1 is opened.
-The formal parameters of a procedure have three major
parts:
1)name :
The name of the parameter, which must be a legal PL/SQL
identifier.
2)mode :
The parameter mode, which indicates whether the parameter
is an input-only parameter (IN), an output-only parameter
(OUT), or is both an input and an output parameter (IN
OUT). If the mode is not specified, IN is assumed.
3)datatype :
The parameter datatype is a standard PL/SQL datatype.

Parameter Modes
-You use parameter modes to define the behavior of formal
parameters.
 - The three parameter modes, IN (the default), OUT,
and IN OUT, can be used with any subprogram.
- However, avoid using the OUT and IN OUT modes with
functions. The purpose of a function is to take
zero or more arguments and return a single value.
It is poor programming practice to have a function
return multiple values. Also, functions should be
free from side effects, which change the values of
variables not local to the subprogram.
Table 7 - 1 summarizes the information about parameter
modes. Parameter modes are explained in detail in the
PL/SQL User's Guide and Reference.
IN OUT IN OUT
the default must be specified must be specified
passes values to a returns values to passes initial
subprogram the caller values to a
subprogram; returns
updated values to
the caller
formal parameter formal parameter formal parameter
acts like a acts like an acts like an
constant uninitialized initialized
variable variable
formal parameter formal parameter formal parameter
cannot be assigned cannot be used in an should be assigned
a value expression; must be a value
assigned a value
actual parameter actual parameter actual parameter
can be a constant, must be a variable must be a variable
initialized
variable, literal,
or expression

Table 7 - 1. Parameter Modes

Parameter Datatypes
The datatype of a formal parameter consists of one of the
following:
• an unconstrained type name, such as NUMBER or
VARCHAR2.
• a type that is constrained using the %TYPE or
%ROWTYPE attributes.
Attention: Numerically constrained types such as
NUMBER(2) or VARCHAR2(20) are not allowed in a parameter
list.
%TYPE and %ROWTYPE Attributes

- However, you can use the type attributes %TYPE and

%ROWTYPE to constrain the parameter.

- For example, the GET_EMP_NAMES procedure

specification could be written as
PROCEDURE get_emp_names(dept_num IN
emp.deptno%TYPE)
- to have the DEPT_NUM parameter take the same
datatype as the DEPTNO column in the EMP table.
The column and table must be available when a
declaration using %TYPE (or %ROWTYPE) is
elaborated.

- Using %TYPE is recommended, since if the type of

the column in the table changes, it is not
necessary to change the application code.

- If the GET_EMP_NAMES procedure is part of a

package, then you can use previously-declared
public (package) variables to constrain a
parameter datatype. For example:
dept_number number(2);
...
PROCEDURE get_emp_names(dept_num IN dept_number%TYPE);
- You use the %ROWTYPE attribute to create a record
that contains all the columns of the specified
table. The following example defines the
GET_EMP_REC procedure, that returns all the
columns of the EMP table in a PL/SQL record, for
the given EMPNO:
PROCEDURE get_emp_rec (emp_number IN emp.empno%TYPE,
emp_ret OUT emp%ROWTYPE) IS
BEGIN
SELECT empno, ename, job, mgr, hiredate, sal, comm,
deptno
INTO emp_ret
FROM emp
WHERE empno = emp_number;
END;
You could call this procedure from a PL/SQL block as
follows:

DECLARE
emp_row emp%ROWTYPE; -- declare a record
matching a
-- row in the EMP table
BEGIN
get_emp_rec(7499, emp_row); -- call for emp# 7499
DBMS_OUTPUT.PUT(emp_row.ename || ' ' || emp_row.empno);
DBMS_OUTPUT.PUT(' ' || emp_row.job || ' ' ||
emp_row.mgr);
DBMS_OUTPUT.PUT(' ' || emp_row.hiredate || ' ' ||
emp_row.sal);
DBMS_OUTPUT.PUT(' ' || emp_row.comm || ' ' ||
emp_row.deptno);
DBMS_OUTPUT.NEW_LINE;
END;
- Stored functions can also return values that are
declared using %ROWTYPE. For example:
FUNCTION get_emp_rec (dept_num IN emp.deptno%TYPE)
RETURN emp%ROWTYPE IS ...
Tables and Records
- You can pass PL/SQL tables as parameters to stored
procedures and functions.
- You can also pass tables of records as parameters.
Default Parameter Values
- Parameters can take default values. You use the
DEFAULT keyword or the assignment operator to give
a parameter a default value. For example, the
specification for the GET_EMP_NAMES procedure
could be written as
PROCEDURE get_emp_names (dept_num IN NUMBER DEFAULT 20)
IS ...
or as
PROCEDURE get_emp_names (dept_num IN NUMBER := 20) IS ...
- When a parameter takes a default value, it can be
omitted from the actual parameter list when you
call the procedure.

- When you do specify the parameter value on the

call, it overrides the default value.
DECLARE Keyword
- Unlike in an anonymous PL/SQL block, you do not
use the keyword DECLARE before the declarations of
variables, cursors, and exceptions in a stored
procedure.
- In fact, it is an error to use it.

Creating Stored Procedures and Functions

 - Use your normal text editor to write the
procedure. At the beginning of the procedure,
place the command
CREATE PROCEDURE procedure_name AS ...
For example, to use the example , you can create a text
(source) file called get_emp.sql containing the following
code:
CREATE PROCEDURE get_emp_rec (emp_number IN
emp.empno%TYPE,
emp_ret OUT emp%ROWTYPE)
AS
BEGIN
SELECT empno, ename, job, mgr, hiredate, sal, comm,
deptno
INTO emp_ret
FROM emp
WHERE empno = emp_number;
END;
- Then, using an interactive too such as SQL*Plus,
load the text file containing the procedure by
entering the command
SQLPLUS> @get_emp
- to load the procedure into the current schema.
(.SQL is the default file extension.) Note the
slash (/) at the end of the code. This is not part
of the code; it just activates the loading of the
procedure.

Note: When developing a new procedure, it is usually

much more convenient to use the CREATE OR REPLACE . . .
PROCEDURE command. This replaces any previous version of
that procedure in the same schema with the newer
version. This is done with no warning.

- You can use either the keyword IS or AS after the

procedure parameter list.

- Use the CREATE [OR REPLACE] FUNCTION . . . command

to store functions. See the Oracle7 Server SQL
Reference for the complete syntax of the CREATE
PROCEDURE and CREATE FUNCTION commands.
Privileges Required to Create Procedures and Functions
- To create a stand-alone procedure or function, or
package specification or body, you must meet the
following prerequisites:
• You must have the CREATE PROCEDURE system privilege
to create a procedure or package in your schema, or
 the CREATE ANY PROCEDURE system privilege to create
a procedure or package in another user's schema.
Attention: To create without errors, that is, to compile
the procedure or package successfully, requires the
following additional privileges:
- The owner of the procedure or package must have
been explicitly granted the necessary object
privileges for all objects referenced within
the body of the code;

- the owner cannot have obtained required

privileges through roles.

- If the privileges of a procedure's or package's

owner change, the procedure must be
reauthenticated before it is executed.

- If a necessary privilege to a referenced object

is revoked from the owner of the procedure (or
package), the procedure cannot be executed.

- The EXECUTE privilege on a procedure gives a

user the right to execute a procedure owned by
another user.

- Privileged users execute the procedure under

the security domain of the procedure's owner.

- Therefore, users never have to be granted the

privileges to the objects referenced by a
procedure.

- This allows for more disciplined and efficient

security strategies with database applications
and their users.

- Furthermore, all procedures and packages are

stored in the data dictionary (in the SYSTEM
tablespace).

- No quota controls the amount of space available

to a user who creates procedures and packages.
Altering Stored Procedures and Functions
- To alter a stored procedure or stored
function, you must:-
1) first DROP it, using the DROP
PROCEDURE or DROP FUNCTION command.
2) then recreate it using the CREATE
PROCEDURE or CREATE FUNCTION command.
 3) Alternatively, use the CREATE OR
REPLACE PROCEDURE or CREATE OR
REPLACE FUNCTION command, which first
drops the procedure or function if it
exists, then recreates it as
specified.
- The procedure or function is dropped with
no warning.
Developers guide:using procedures & functions

An Introduction to Stored Procedures and Packages

- Oracle allows you to access and manipulate
database information using procedural schema
objects called PL/SQL program units.
- Procedures, functions, and packages are all
examples of PL/SQL program units.
Stored Procedures and Functions
- A procedure or function is a schema object that
logically groups a set of SQL and other PL/SQL
programming language statements together to
perform a specific task.
- Procedures and functions are created in a user's
schema and stored in a database for continued use.
- You can execute a procedure or function
interactively using an Oracle tool, such as
SQL*Plus, or call it explicitly in the code of a
database application, such as an Oracle Forms or
Precompiler application, or in the code of another
procedure or trigger.

Figure 14 - 1 illustrates a simple procedure stored

in the database, being called by several different
database applications.
Figure 14 - 1. A Stored Procedure
The stored procedure in Figure 14 - 1, which inserts an
employee record into the EMP table, is shown in Figure 14
- 2.

Figure 14 - 2. The HIRE_EMP Procedure

All of the database applications in Figure 14 - 1 call
the HIRE_EMP procedure.
Alternatively, a privileged user might use Server Manager
to execute the HIRE_EMP procedure using the following
statement:
EXECUTE hire_emp ('TSMITH', 'CLERK', 1037, SYSDATE, \
500, NULL, 20);
This statement places a new employee record for TSMITH in
the EMP table.
Packages
- A package is a group of related procedures and
functions, together with the cursors and variables
they use, stored together in the database for
continued use as a unit.
- Similar to standalone procedures and functions,
packaged procedures and functions can be called
explicitly by applications or users.
- Figure 14 - 3 illustrates a package that
encapsulates a number of procedures used to manage
an employee database.
Figure 14 - 3. A Stored Package

- Database applications explicitly call packaged

procedures as necessary.

- After being granted the privileges for the

EMP_MGMT package, a user can explicitly execute
any of the procedures contained in it. For
example, the following statement might be issued
 using Server Manager to execute the HIRE_EMP
package procedure:
EXECUTE emp_mgmt.hire_emp ('TSMITH', 'CLERK', 1037, \
SYSDATE, 500, NULL, 20);
- Packages offer several development and performance
advantages over standalone stored procedures.

- These advantages are described in the section

"Packages" .
PL/SQL
- PL/SQL is Oracle's procedural language extension
to SQL.
- It extends SQL with flow control and other
statements that make it possible to write complex
programs in it.
- The PL/SQL engine is the tool you use to define,
compile, and execute PL/SQL program units.
- This engine is a special component of many Oracle
products, including Oracle Server.
- While many Oracle products have PL/SQL components,
this chapter specifically covers the procedures
and packages that can be stored in an Oracle
database and processed using the Oracle Server
PL/SQL engine.

- The PL/SQL capabilities of each Oracle tool are

described in the appropriate tool's documentation.

Procedures and Functions

- Oracle can process procedures and functions as
well as individual SQL statements.
- A procedure or function is a schema object that
consists of a set of SQL statements and other
PL/SQL constructs, grouped together, stored in the
database, and executed as a unit to solve a
specific problem or perform a set of related
tasks.
- Procedures and functions permit the caller to
provide parameters that can be input only, output
only, or input and output values.
- Procedures and functions allow you to combine the
ease and flexibility of SQL with the procedural
functionality of a structured programming
language.
For example, the following statement creates the
CREDIT_ACCOUNT procedure, which credits money to a bank
account:
CREATE PROCEDURE credit_account
(acct NUMBER, credit NUMBER) AS

/* This procedure accepts two arguments: an account

number and an amount of money to credit to the
specified
account. If the specified account does not exist, a
new account is created. */

old_balance NUMBER;
new_balance NUMBER;
BEGIN
SELECT balance INTO old_balance FROM accounts
WHERE acct_id = acct
FOR UPDATE OF balance;
new_balance := old_balance + credit;
UPDATE accounts SET balance = new_balance
WHERE acct_id = acct;
COMMIT;

EXCEPTION
WHEN NO_DATA_FOUND THEN
INSERT INTO accounts (acct_id, balance)
VALUES(acct, credit);
WHEN OTHERS THEN
ROLLBACK;
END credit_account;
- Notice that both SQL and PL/SQL statements are
included in the CREDIT_ACCOUNT procedure.

- Procedures and functions are nearly identical. The

only differences are that functions always return
a single value to the caller, while procedures do
not.

- For simplicity, the term "procedure" is used in

the remainder of this chapter to mean "procedures
and functions," unless otherwise noted.
How Procedures Are Used
You should design and use all stored procedures so that
they have the following properties:
• Define procedures to complete a single, focused
task. Do not define long procedures with several
distinct subtasks, or subtasks common to many
procedures might be duplicated unnecessarily in the
code of several procedures.
• Do not define procedures that duplicate the
functionality already provided by other features of
Oracle. For example, do not define procedures to
 enforce simple data integrity rules that you could
easily enforce using declarative integrity
constraints.
Applications for Procedures
Procedures provide advantages in the following areas:
• security
• performance
• memory allocation
• productivity
• integrity
Security
- Stored procedures can help enforce data
security.
- You can restrict the database operations that
users can perform by allowing them to access
data only through procedures and functions.
- For example, you can grant users access to a
procedure that updates a table, but not grant
them access to the table itself.

- When a user invokes the procedure, the

procedure executes with the privileges of the
procedure's owner.

- Users that have only the privilege to execute

the procedure and not the privileges to query,
update, or delete from the underlying tables,
can invoke the procedure, but they cannot
manipulate table data in any other way.
Performance
- Stored procedures can improve database
performance.
- Use of procedures dramatically reduces the amount
of information that must be sent over a network
compared to issuing individual SQL statements or
sending the text of an entire PL/SQL block to
Oracle, because the information is sent only once
and thereafter invoked when it is used.
- Furthermore, because a procedure's compiled form
is readily available in the database, no
compilation is required at execution time.
- Additionally, if the procedure is already present
in the shared pool of the SGA, retrieval from disk
 is not required, and execution can begin
immediately.
Memory Allocation
- Because stored procedures take advantage of the
shared memory capabilities of Oracle, only a
single copy of the procedure needs to be loaded
into memory for execution by multiple users.
- Sharing the same code among many users results in
a substantial reduction in Oracle memory
requirements for applications.
Productivity
- Stored procedures increase development
productivity.
- By designing applications around a common set of
procedures, you can avoid redundant coding and
increase your productivity.
For example:

- procedures can be written to insert, update, or

delete rows from the EMP table.

- These procedures can then be called by any

application without rewriting the SQL statements
necessary to accomplish these tasks.

- If the methods of data management change, only

the procedures need to be modified, not all of
the applications that use the procedures.
Integrity
- Stored procedures improve the integrity and
consistency of your applications.
- By developing all of your applications around a
common group of procedures, you can reduce the
likelihood of committing coding errors.
For example:

- you can test a procedure or function to guarantee

that it returns an accurate result and, once it
is verified, reuse it in any number of
applications without testing it again.

- If the data structures referenced by the

procedure are altered in any way, only the
procedure needs to be recompiled; applications
that call the procedure do not necessarily
require any modifications.
Anonymous PL/SQL Blocks vs. Stored Procedures
- You create an anonymous PL/SQL block by sending an
unnamed PL/SQL block to Oracle Server from an
Oracle tool or an application.
- Oracle compiles the PL/SQL block and places the
compiled version in the shared pool of the SGA,
but does not store the source code or compiled
version in the database for subsequent reuse.
- Shared SQL allows a compiled anonymous PL/SQL
block already in the shared pool to be reused and
shared until it is flushed out of the shared pool.

- Alternatively, a stored procedure is created and

stored in the database as an object.

- Once created and compiled, it is a named object

that can be executed without recompiling.

- Additionally, dependency information is stored in

the data dictionary to guarantee the validity of
each stored procedure.

- In summary, by moving PL/SQL blocks out of a

database application and into stored database
procedures, you avoid unnecessary procedure
recompilations by Oracle at runtime, improving the
overall performance of the application and Oracle.
Standalone Procedures vs. Package Procedures
- Stored procedures not defined within the context
of a package are called standalone procedures.
- Procedures defined within a package are considered
a part of the package. See "Packages" for
information on the advantages of packages.
Dependency Tracking for Stored Procedures
- A stored procedure is dependent on the objects
referenced in its body.
- Oracle automatically tracks and manages such
dependencies.
- For example, if you alter the definition of a
table referenced by a procedure, the procedure
must be recompiled to validate that it will
continue to work as designed.
- Usually, Oracle automatically administers such
dependency management.

See Chapter 16, "Dependencies Among Schema Objects", for

more information about dependency tracking.
Packages
- Packages provide a method of encapsulating related
procedures, functions, and associated cursors and
variables together as a unit in the database.
- For example, the following two statements create
the specification and body for a package that
contains several procedures and functions that
process banking transactions.
CREATE PACKAGE bank_transactions AS
minimum_balance CONSTANT NUMBER := 100.00;
PROCEDURE apply_transactions;
PROCEDURE enter_transaction (acct NUMBER,
kind CHAR,
amount NUMBER);
END bank_transactions;

CREATE PACKAGE BODY bank_transactions AS

/* Package to input bank transactions */

new_status CHAR(20); /* Global variable to record

status
of transaction being applied.
Used
for update in
APPLY_TRANSACTIONS. */

PROCEDURE do_journal_entry (acct NUMBER,

kind CHAR) IS

/* Records a journal entry for each bank transaction

applied
by the APPLY_TRANSACTIONS procedure. */

BEGIN
INSERT INTO journal
VALUES (acct, kind, sysdate);
IF kind = 'D' THEN
new_status := 'Debit applied';
ELSIF kind = 'C' THEN
new_status := 'Credit applied';
ELSE
new_status := 'New account';
END IF;
END do_journal_entry;

(continued next page)

PROCEDURE credit_account (acct NUMBER, credit NUMBER)
IS
/* Credits a bank account the specified amount. If the
account
does not exist, the procedure creates a new account
first. */

old_balance NUMBER;
new_balance NUMBER;

BEGIN
SELECT balance INTO old_balance FROM accounts
WHERE acct_id = acct
FOR UPDATE OF balance; /* Locks account for
credit update */
new_balance := old_balance + credit;
UPDATE accounts SET balance = new_balance
WHERE acct_id = acct;
do_journal_entry(acct, 'C');

EXCEPTION
WHEN NO_DATA_FOUND THEN /* Create new account if
not found */
INSERT INTO accounts (acct_id, balance)
VALUES(acct, credit);
do_journal_entry(acct, 'N');
WHEN OTHERS THEN /* Return other errors to
application */
new_status := 'Error: ' || SQLERRM(SQLCODE);
END credit_account;

PROCEDURE debit_account (acct NUMBER, debit NUMBER) IS

/* Debits an existing account if result is greater than

the
allowed minimum balance. */

old_balance NUMBER;
new_balance NUMBER;
insufficient_funds EXCEPTION;

BEGIN
SELECT balance INTO old_balance FROM accounts
WHERE acct_id = acct
FOR UPDATE OF balance;
new_balance := old_balance - debit;
IF new_balance >= minimum_balance THEN
UPDATE accounts SET balance = new_balance
WHERE acct_id = acct;
do_journal_entry(acct, 'D');
ELSE
RAISE insufficient_funds;
END IF;
(continued next page)
EXCEPTION
WHEN NO_DATA_FOUND THEN
new_status := 'Nonexistent account';
WHEN insufficient_funds THEN
new_status := 'Insufficient funds';
WHEN OTHERS THEN /* Returns other errors to
application */
new_status := 'Error: ' || SQLERRM(SQLCODE);
END debit_account;

PROCEDURE apply_transactions IS

/* Applies pending transactions in the table TRANSACTIONS

to the
ACCOUNTS table. Used at regular intervals to update
bank
accounts without interfering with input of new
transactions. */

/* Cursor fetches and locks all rows from the

TRANSACTIONS
table with a status of 'Pending'. Locks released after
all pending transactions have been applied. */

CURSOR trans_cursor IS
SELECT acct_id, kind, amount FROM transactions
WHERE status = 'Pending'
ORDER BY time_tag
FOR UPDATE OF status;

BEGIN
FOR trans IN trans_cursor LOOP /* implicit open
and fetch */
IF trans.kind = 'D' THEN
debit_account(trans.acct_id, trans.amount);
ELSIF trans.kind = 'C' THEN
credit_account(trans.acct_id, trans.amount);
ELSE
new_status := 'Rejected';
END IF;
/* Update TRANSACTIONS table to return result of
applying
this transaction. */
UPDATE transactions SET status = new_status
WHERE CURRENT OF trans_cursor;
END LOOP;
COMMIT; /* Release row locks in TRANSACTIONS table. */
END apply_transactions;
(continued next page)
PROCEDURE enter_transaction (acct NUMBER,
kind CHAR,
amount NUMBER) IS

/* Enters a bank transaction into the TRANSACTIONS table.

A new
transaction is always input into this 'queue' before
being
applied to the specified account by the
APPLY_TRANSACTIONS
procedure. Therefore, many transactions can be
simultaneously
input without interference. */

BEGIN
INSERT INTO transactions
VALUES (acct, kind, amount, 'Pending', sysdate);
COMMIT;
END enter_transaction;

END bank_transactions;
- While packages allow the database administrator or
application developer to organize similar
routines, they also offer increased functionality
and database performance.
Applications for Packages
Packages are used to define related procedures,
variables, and cursors and are often implemented to
provide advantages in the following areas:
• encapsulation of related procedures and variables
• declaration of public and private procedures,
variables, constants, and cursors
• separation of the package specification and package
body
• better performance
Encapsulation
- Stored packages allow you to encapsulate, or
group, related stored procedures, variables,
datatypes, etc. in a single named, stored unit
in the database. This provides for better
organization during the development process.
- Encapsulation of procedural constructs in a
package also makes privilege management easier.
 - Granting the privilege to use a package makes
all constructs of the package accessible to the
grantee.
Public and Private Data and Procedures
- The methods of package definition allow you to
specify which variables, cursors, and procedures
are
public
Directly accessible to the user of a package.
private
Hidden from the user of a package.

- For example, a package might contain ten

procedures. However, the package can be defined so
that only three procedures are public and
therefore available for execution by a user of the
package; the remainder of the procedures are
private and can only be accessed by the procedures
within the package.

- Do not confuse public and private package

variables with grants to PUBLIC, which are
described in Chapter 17, "Database Access".
Separate Package Specification and Package Body
You create a package in two parts:
- the specification and the body.
- A package's specification declares all public
constructs of the package.
- the body defines all constructs (public and
private) of the package.
- This separation of the two parts provides the
following advantages:
• By defining the package specification separately
from the package body, the developer has more
flexibility in the development cycle. You can create
specifications and reference public procedures
without actually creating the package body.
• You can alter procedure bodies contained within the
package body separately from their publicly declared
specifications in the package specification. As long
as the procedure specification does not change,
objects that reference the altered procedures of the
package are never marked invalid; that is, they are
never marked as needing recompilation. For more
 information about dependencies, see Chapter 16,
"Dependencies Among Schema Objects".
Performance Improvement
Using packages rather than stand-alone stored procedures
results in the following improvements:
• The entire package is loaded into memory when a
procedure within the package is called for the first
time. This load is completed in one operation, as
opposed to the separate loads required for
standalone procedures. Therefore, when calls to
related packaged procedures occur, no disk I/O is
necessary to execute the compiled code already in
memory.
• A package body can be replaced and recompiled
without affecting the specification. As a result,
objects that reference a package's constructs
(always via the specification) never need to be
recompiled unless the package specification is also
replaced. By using packages, unnecessary
recompilations can be minimized, resulting in less
impact on overall database performance.
Dependency Tracking for Packages
- A package is dependent on the objects
referenced by the procedures and functions
defined in its body.
- Oracle automatically tracks and manages such
dependencies.

See Chapter 16, "Dependencies Among Schema Objects", for

more information about dependency tracking.

How Oracle Stores Procedures and Packages

When you create a procedure or package, Oracle
automatically performs these steps:
1. Compiles the procedure or package.
2. Stores the compiled code in memory.
3. Stores the procedure or package in the database.
Compiling Procedures and Packages
- The PL/SQL compiler compiles the source code.
- The PL/SQL compiler is part of the PL/SQL engine
contained in Oracle.
- If an error occurs during compilation, a message
is returned.
- Information on identifying compilation errors is
contained in the Oracle7 Server Application
Developer's Guide.
Storing the Compiled Code in Memory
- Oracle caches the compiled procedure or package in
the shared pool of the SGA.
- This allows the code to be executed quickly and
shared among many users.
- The compiled version of the procedure or package
remains in the shared pool according to the
modified least-recently-used algorithm used by the
shared pool, even if the original caller of the
procedure terminates his/her session. See "The
Shared Pool" for specific information about the
shared pool buffer.
Storing Procedures or Packages in Database
At creation and compile time, Oracle automatically stores
the following information about a procedure or package in
the database:
object name :

- Oracle uses this name to identify the procedure or

package.

- You specify this name in the CREATE PROCEDURE,

CREATE FUNCTION, CREATE PACKAGE, or CREATE PACKAGE
BODY statement.
source code and parse tree :

- The PL/SQL compiler parses the source code and

produces a parsed representation of the source
code, called a parse tree.
pseudocode (P code) :

- The PL/SQL compiler generates the pseudocode, or P

code, based on the parsed code.

- The PL/SQL engine executes this when the

procedure or package is invoked.
error messages :

- Oracle might generate errors during the

compilation of a procedure or package.
To avoid unnecessary recompilation of a procedure or
package, both the parse tree and the P code of an object
are stored in the database. This allows the PL/SQL engine
to read the compiled version of a procedure or package
into the shared pool buffer of the SGA when it is invoked
and not currently in the SGA. The parse tree is used when
the code calling the procedure is compiled.
 - All parts of database procedures are stored in the
data dictionary (which is in the SYSTEM
tablespace) of the corresponding database.

- The database administrator should plan the size of

the SYSTEM tablespace, keeping in mind that all
stored procedures require space in this
tablespace.

How Oracle Executes Procedures and Packages

When you invoke a standalone or packaged procedure,
Oracle performs these steps to execute it:
1. Verifies user access.
2. Verifies procedure validity.
3. Executes the procedure.
Verifying User Access
- Oracle verifies that the calling user owns or has
the EXECUTE privilege on the procedure or
encapsulating package.
- The user who executes a procedure does not require
access to any procedures or objects referenced
within the procedure; only the creator of a
procedure or package requires privileges to access
referenced schema objects.
Verifying Procedure Validity
Oracle checks the data dictionary to see if the status
of the procedure or package is valid or invalid. A
procedure or package is invalid when one of the
following has occurred since the procedure or package
was last compiled:
• One or more of the objects referenced within the
procedure or package (such as tables, views, and
other procedures) have been altered or dropped (for
example, if a user added a column to a table).
• A system privilege that the package or procedure
requires has been revoked from PUBLIC or from the
owner of the procedure or package.
• A required object privilege for one or more of the
objects referenced by a procedure or package has
been revoked from PUBLIC or from the owner of the
procedure or package.
A procedure is valid if it has not been invalidated by
any of the above operations.
• If a valid standalone or packaged procedure is
called, the compiled code is executed.
 • If an invalid standalone or packaged procedure
is called, it is automatically recompiled
before being executed.
For a complete discussion of valid and invalid procedures
and packages, recompiling procedures, and a thorough
discussion of dependency issues, see Chapter 16,
"Dependencies Among Schema Objects".
Executing a Procedure
The PL/SQL engine executes the procedure or package using
different steps, depending on the situation:
• If the procedure is valid and currently in memory,
the PL/SQL engine simply executes the P code.
• If the procedure is valid and currently not in
memory, the PL/SQL engine loads the compiled P code
from disk to memory and executes it. For packages,
all constructs of the package (all procedures,
variables, and so on, compiled as one executable
piece of code) are loaded as a unit.
The PL/SQL engine processes a procedure statement by
statement, handling all procedural statements by
itself and passing SQL statements to the SQL
statement executor, as illustrated in Figure 11 - 1
.
CREATE PROCEDURE
Purpose
To create a stand-alone stored procedure. A procedure is
a group of PL/SQL statements that you can call by name.
Prerequisites
• Before a procedure can be created, the user SYS must
run the SQL script DBMSSTDX.SQL.
• The exact name and location of this script may vary
depending on your operating system.
• To create a procedure in your own schema, you must
have CREATE PROCEDURE system privilege.
• To create a procedure in another schema, you must
have CREATE ANY PROCEDURE system privilege.
• To replace a procedure in another schema, you must
have REPLACE ANY PROCEDURE system privilege.
• If you are using Trusted Oracle7 in DBMS MAC mode,
you can only create a procedure in another user's
schema if your DBMS label dominates the creation
label of the other user.
 • To create a procedure, you must be using Oracle7
with PL/SQL installed. For more information, see
PL/SQL User's Guide and Reference.
Syntax

Keywords and Parameters

OR REPLACE

- recreates the procedure if it already

exists.

- You can use this option to change

the definition of an existing
procedure without dropping,
recreating, and regranting object
privileges previously granted on it.

- If you redefine a procedure, Oracle7

recompiles it. For information on
recompiling procedures, see the ALTER
PROCEDURE command .

- Users who had previously been granted

privileges on a redefined procedure
can still access the procedure
without being regranted the
privileges.
schema

- is the schema to contain the

procedure.

- If you omit schema, Oracle7 creates

the procedure in your current schema.

procedure
is the name of the procedure to be created.
argument

- is the name of an argument to the

procedure.

- If the procedure does not accept

arguments, you can omit the
parentheses following the procedure
name.
IN
specifies that you must specify a value for the argument
when calling the procedure.
OUT
specifies that the procedure passes a value for this
argument back to its calling environment after execution.
IN OUT
specifies that you must specify a value for the argument
when calling the procedure and that the procedure passes
a value back to its calling environment after execution.
If you omit IN, OUT, and IN OUT, the argument defaults to
IN.
datatype

- is the datatype of an argument.

- As long as no length specifier is

used, an argument can have any
datatype supported by PL/SQL.

- Datatypes are specified without a

length, precision, or scale. For
example, VARCHAR2(10) is not valid,
but VARCHAR2 is valid.

- Oracle7 derives the length,

precision, or scale of an argument
from the environment from which the
procedure is called.

pl/sql_subprogram_body

- is the definition of the procedure.

 - Procedure definitions are written in
PL/SQL.

- To embed a CREATE PROCEDURE statement

inside an Oracle Precompiler program,
you must terminate the statement with
the keyword END-EXEC followed by the
embedded SQL statement terminator for
the specific language.
Usage Notes
- A procedure is a group of PL/SQL
statements that you can call by name.
- Stored procedures and stored
functions are similar in many ways.
- This discussion applies to functions
as well as to procedures. For
information specific to functions,
see the CREATE FUNCTION command .
- With PL/SQL, you can group multiple
SQL statements together with
procedural PL/SQL statements similar
to those in programming languages
such as Ada and C.

- With the CREATE PROCEDURE command,

you can create a procedure and store
it in the database.

- You can call a stored procedure from

any environment from which you can
issue a SQL statement.
Stored procedures offer you advantages in the following
areas:
• development
• integrity
• security
• performance
• memory allocation
For more information on stored procedures, including how
to call stored procedures, see the "Using Procedures and
Packages" chapter of Oracle7 Server Application
Developer's Guide.
- When you create a procedure in Trusted Oracle7,
it is labeled with your DBMS label.
 - The CREATE PROCEDURE command creates a
procedure as a stand-alone schema object. You
can also create a procedure as part of a
package. For information on creating packages,
see the CREATE PACKAGE command .
Example
The following statement creates the procedure CREDIT in
the schema SAM:
CREATE PROCEDURE sam.credit (acc_no IN NUMBER, amount IN
NUMBER)
AS BEGIN
UPDATE accounts
SET balance = balance + amount
WHERE account_id = acc_no;
END;
The CREDIT procedure credits a specified bank account
with a specified amount. When you call the procedure, you
must specify the following arguments:
ACC_NO
This argument is the number of the bank account to be
credited. The argument's datatype is NUMBER.
AMOUNT
This argument is the amount of the credit. The argument's
datatype is NUMBER.
The procedure uses an UPDATE statement to increase the
value in the BALANCE column of the ACCOUNTS table by the
value of the argument AMOUNT for the account identified
by the argument ACC_NO.

Procedures
Description
A procedure is a named PL/SQL block, which can take
parameters and be invoked. Generally, you use a procedure
to perform an action. For more information, see
"Procedures" .
A procedure has two parts: the specification and the
body. The procedure specification begins with the keyword
PROCEDURE and ends with the procedure name or a parameter
list. Parameter declarations are optional. Procedures
that take no parameters are written without parentheses.
The procedure body begins with the keyword IS and ends
with the keyword END followed by an optional procedure
name. The procedure body has three parts: an optional
declarative part, an executable part, and an optional
exception-handling part.
The declarative part contains declarations of types,
cursors, constants, variables, exceptions, and
subprograms. These objects are local and cease to exist
when you exit the procedure. The executable part contains
statements that assign values, control execution, and
manipulate Oracle data. The exception-handling part
contains exception handlers, which deal with exceptions
raised during execution.
Syntax
procedure_specification ::=
PROCEDURE procedure_name (parameter_declaration[,
parameter_declaration]...)];
procedure_body ::=
PROCEDURE procedure_name [(parameter_declaration[,
parameter_declaration]...)] IS
[[object_declaration [object_declaration] ...]
[subprogram_declaration [subprogram_declaration]
...]]
BEGIN
seq_of_statements
[EXCEPTION
exception_handler [exception_handler] ...]
END [procedure_name];
parameter_declaration ::=
parameter_name [IN | OUT | IN OUT]
{ cursor_name%ROWTYPE
| cursor_variable_name%TYPE
| plsql_table_name%TYPE
| record_name%TYPE
| scalar_type_name
| table_name%ROWTYPE
| table_name.column_name%TYPE
| variable_name%TYPE} [{:= | DEFAULT} expression]
object_declaration ::=
{ constant_declaration
| cursor_declaration
| cursor_variable_declaration
| exception_declaration
| plsql_table_declaration
| record_declaration
| variable_declaration}
subprogram_declaration ::=
{function_declaration | procedure_declaration}
procedure_name
This identifies a user-defined procedure. For naming
conventions, see "Identifiers" .
parameter_name
This identifies a formal parameter, which is a variable
declared in a procedure specification and referenced in
the procedure body.
IN, OUT, IN OUT
These parameter modes define the behavior of formal
parameters. An IN parameter lets you pass values to the
subprogram being called. An OUT parameter lets you return
values to the caller of the subprogram. An IN OUT
parameter lets you pass initial values to the subprogram
being called and return updated values to the caller.
:= | DEFAULT
This operator or keyword allows you to initialize IN
parameters to default values.
expression
This is an arbitrarily complex combination of variables,
constants, literals, operators, and function calls. The
simplest expression consists of a single variable. For
the syntax of expression, see "Expressions" on page 10 -
41. When the declaration is elaborated, the value of
expression is assigned to the parameter. The value and
the parameter must have compatible datatypes.

DROP PROCEDURE
Purpose
To remove a stand-alone stored procedure from the database.
Prerequisites
The procedure must be in your own schema or you must have DROP ANY PROCEDURE system
privilege.
If you are using Trusted Oracle7 in DBMS MAC mode, your DBMS label must match
the cluster's creation label or you must satisfy one of the following criteria:
• If the procedure's creation label is higher than your DBMS label, you must have READUP and
WRITEUP system privileges

• If the procedure's creation label is lower than your DBMS label, you must have
WRITEDOWN system privilege.

• If the procedure's creation label and your DBMS label are not comparable, you must have
READUP, WRITEUP, and WRITEDOWN system privileges.

Syntax
Keywords and Parameters
schema
is the schema containing the procedure. If you omit schema, Oracle7 assumes the
procedure is in your own schema.
procedure
is the name of the procedure to be dropped.

Usage Notes
When you drop a procedure, Oracle7 invalidates any local objects that depend upon the dropped
procedure. If you subsequently reference one of these objects, Oracle7 tries to recompile the object and
returns an error message if you have not recreated the dropped procedure.
For information on how Oracle7 maintains dependencies among schema objects,
including remote objects.
You can only use this command to drop a stand-alone procedure. To remove a
procedure that is part of a package, use one of the following methods:
• Drop the entire package using the DROP PACKAGE command.

• Redefine the package without the procedure using the CREATE PACKAGE command with
the OR REPLACE option.
Example
The following statement drops the procedure TRANSFER owned by the user
KERNER:
DROP PROCEDURE kerner.transfer
When you drop the TRANSFER procedure, Oracle7 invalidates all objects that
depend upon TRANSFER.