|Oracle® Database PL/SQL Language Reference
11g Release 1 (11.1)
|PDF · Mobi · ePub|
Static SQL is SQL that belongs to the PL/SQL language; that is:
Data Manipulation Language (DML) Statements (except
To manipulate database data, you can include DML operations, such as
DELETE statements, directly in PL/SQL programs, without any special notation, as shown in Example 6-1. You can also include the SQL
COMMIT statement directly in a PL/SQL program; see Overview of Transaction Processing in PL/SQL.
CREATE TABLE employees_temp AS SELECT employee_id, first_name, last_name FROM employees; DECLARE emp_id employees_temp.employee_id%TYPE; emp_first_name employees_temp.first_name%TYPE; emp_last_name employees_temp.last_name%TYPE; BEGIN INSERT INTO employees_temp VALUES(299, 'Bob', 'Henry'); UPDATE employees_temp SET first_name = 'Robert' WHERE employee_id = 299; DELETE FROM employees_temp WHERE employee_id = 299 RETURNING first_name, last_name INTO emp_first_name, emp_last_name; COMMIT; DBMS_OUTPUT.PUT_LINE( emp_first_name || ' ' || emp_last_name); END; /
See Also:Oracle Database SQL Language Referencefor information about the
To find out how many rows are affected by DML statements, you can check the value of
SQL%ROWCOUNT as shown in Example 6-2.
CREATE TABLE employees_temp AS SELECT * FROM employees; BEGIN UPDATE employees_temp SET salary = salary * 1.05 WHERE salary < 5000; DBMS_OUTPUT.PUT_LINE('Updated ' || SQL%ROWCOUNT || ' salaries.'); END; /
Wherever you can use literal values, or bind variables in some other programming language, you can directly substitute PL/SQL variables as shown in Example 6-3.
CREATE TABLE employees_temp AS SELECT first_name, last_name FROM employees; DECLARE x VARCHAR2(20) := 'my_first_name'; y VARCHAR2(25) := 'my_last_name'; BEGIN INSERT INTO employees_temp VALUES(x, y); UPDATE employees_temp SET last_name = x WHERE first_name = y; DELETE FROM employees_temp WHERE first_name = x; COMMIT; END; /
With this notation, you can use variables in place of values in the
WHERE clause. To use variables in place of table names, column names, and so on, requires the
IMMEDIATE statement that is explained in Using Native Dynamic SQL.
For more information about assigning values to PL/SQL variables, see Assigning SQL Query Results to PL/SQL Variables.
Note:When issuing a data manipulation (DML) statement in PL/SQL, there are some situations when the value of a variable is undefined after the statement is executed. These include:
SELECT statement raises any exception, then the values of the define variables after that statement are undefined.
If a DML statement affects zero rows, the values of the
OUT binds after the DML executes are undefined. This does not apply to a
BULK or multiple-row operation.
The database is transaction oriented; that is, the database uses transactions to ensure data integrity. A transaction is a series of SQL data manipulation statements that does a logical unit of work. For example, two
UPDATE statements might credit one bank account and debit another. It is important not to allow one operation to succeed while the other fails.
At the end of a transaction that makes database changes, the database makes all the changes permanent or undoes them all. If your program fails in the middle of a transaction, the database detects the error and rolls back the transaction, restoring the database to its former state.
You use the
TRANSACTION statements to control transactions.
COMMIT makes permanent any database changes made during the current transaction.
ROLLBACK ends the current transaction and undoes any changes made since the transaction began.
SAVEPOINT marks the current point in the processing of a transaction. Used with
SAVEPOINT undoes part of a transaction.
TRANSACTION sets transaction properties such as read/write access and isolation level. See Overview of Transaction Processing in PL/SQL.
The queries in Example 6-4 invoke a SQL function (
PL/SQL recognizes the SQL pseudocolumns
ROWNUM. However, there are limitations on the use of pseudocolumns, including the restriction on the use of some pseudocolumns in assignments or conditional tests. For more information, including restrictions, on the use of SQL pseudocolumns, see Oracle Database SQL Language Reference.
A sequence is a schema object that generates sequential numbers. When you create a sequence, you can specify its initial value and an increment.
CURRVAL returns the current value in a specified sequence. Before you can reference
CURRVAL in a session, you must use
NEXTVAL to generate a number. A reference to
NEXTVAL stores the current sequence number in
NEXTVAL increments the sequence and returns the next value. To get the current or next value in a sequence, use dot notation:
sequence_name can be either local or remote.
Each time you reference the
NEXTVAL value of a sequence, the sequence is incremented immediately and permanently, whether you commit or roll back the transaction.
After creating a sequence, you can use it to generate unique sequence numbers for transaction processing.
Example 6-5 generates a new sequence number and refers to that number in more than one statement. (The sequence must already exist. To create a sequence, use the SQL statement
CREATE TABLE employees_temp AS SELECT employee_id, first_name, last_name FROM employees; CREATE TABLE employees_temp2 AS SELECT employee_id, first_name, last_name FROM employees; DECLARE seq_value NUMBER; BEGIN -- Generate initial sequence number seq_value := employees_seq.NEXTVAL; -- Print initial sequence number: DBMS_OUTPUT.PUT_LINE ('Initial sequence value: ' || TO_CHAR(seq_value)); -- Use NEXTVAL to create unique number when inserting data: INSERT INTO employees_temp VALUES (employees_seq.NEXTVAL, 'Lynette', 'Smith'); -- Use CURRVAL to store same value somewhere else: INSERT INTO employees_temp2 VALUES (employees_seq.CURRVAL, 'Morgan', 'Smith'); -- Because NEXTVAL values might be referenced -- by different users and applications, -- and some NEXTVAL values might not be stored in the database, -- there might be gaps in the sequence. -- Use CURRVAL to specify the record to delete: seq_value := employees_seq.CURRVAL; DELETE FROM employees_temp2 WHERE employee_id = seq_value; -- Udpate employee_id with NEXTVAL for specified record: UPDATE employees_temp SET employee_id = employees_seq.NEXTVAL WHERE first_name = 'Lynette' AND last_name = 'Smith'; -- Display final value of CURRVAL: seq_value := employees_seq.CURRVAL; DBMS_OUTPUT.PUT_LINE ('Ending sequence value: ' || TO_CHAR(seq_value)); END; /
You can use
NEXTVAL wherever you can use a
NEXTVAL to provide a default value for an object type method parameter causes a compilation error.
PL/SQL evaluates every occurrence of
NEXTVAL (unlike SQL, which evaluates a sequence expression only once for every row in which it appears).
LEVEL with the
BY statement to organize rows from a database table into a tree structure. You might use sequence numbers to give each row a unique identifier, and refer to those identifiers from other rows to set up parent-child relationships.
LEVEL returns the level number of a node in a tree structure. The root is level 1, children of the root are level 2, grandchildren are level 3, and so on.
WITH clause, you specify a condition that identifies the root of the tree. You specify the direction in which the query traverses the tree (down from the root or up from the branches) with the
When you select or fetch a physical rowid into a
UROWID variable, you can use the function
ROWIDTOCHAR, which converts the binary value to a character string. You can compare the
UROWID variable to the
ROWID pseudocolumn in the
WHERE clause of an
DELETE statement to identify the latest row fetched from a cursor. For an example, see Fetching Across Commits.
ROWNUM returns a number indicating the order in which a row was selected from a table. The first row selected has a
ROWNUM of 1, the second row has a
ROWNUM of 2, and so on. If a
SELECT statement includes an
ROWNUMs are assigned to the retrieved rows before the sort is done; use a subselect to get the first n sorted rows. The value of
ROWNUM increases only when a row is retrieved, so the only meaningful uses of
ROWNUM in a
WHERE clause are:
... WHERE ROWNUM < constant; ... WHERE ROWNUM <= constant;
You can use
ROWNUM in an
UPDATE statement to assign unique values to each row in a table, or in the
WHERE clause of a
SELECT statement to limit the number of rows retrieved, as shown in Example 6-6.
CREATE TABLE employees_temp AS SELECT * FROM employees; DECLARE CURSOR c1 IS SELECT employee_id, salary FROM employees_temp WHERE salary > 2000 AND ROWNUM <= 10; -- 10 arbitrary rows CURSOR c2 IS SELECT * FROM (SELECT employee_id, salary FROM employees_temp WHERE salary > 2000 ORDER BY salary DESC) WHERE ROWNUM < 5; -- first 5 rows, in sorted order BEGIN -- Each row gets assigned a different number UPDATE employees_temp SET employee_id = ROWNUM; END; /
PL/SQL lets you use all the SQL comparison, set, and row operators in SQL statements. This section briefly describes some of these operators. For more information, see Oracle Database SQL Language Reference.
Typically, you use comparison operators in the
WHERE clause of a data manipulation statement to form predicates, which compare one expression to another and yield
NULL. You can use the comparison operators in the following list to form predicates. You can combine predicates using the logical operators
||Compares a value to each value in a list or returned by a subquery and yields
||Compares a value to each value in a list or returned by a subquery and yields
||Tests whether a value lies in a specified range.|
||Tests for set membership.|
||Tests for nulls.|
||Tests whether a character string matches a specified pattern, which can include wildcards.|
Set operators combine the results of two queries into one result.
INTERSECT returns all distinct rows selected by both queries.
MINUS returns all distinct rows selected by the first query but not by the second.
UNION returns all distinct rows selected by either query.
ALL returns all rows selected by either query, including all duplicates.
Row operators return or reference particular rows.
ALL retains duplicate rows in the result of a query or in an aggregate expression.
DISTINCT eliminates duplicate rows from the result of a query or from an aggregate expression.
PRIOR refers to the parent row of the current row returned by a tree-structured query.
PL/SQL uses implicit and explicit cursors. PL/SQL declares a cursor implicitly for all SQL data manipulation statements, including queries that return only one row. Implicit cursors are called SQL cursors. If you want precise control over query processing, you can declare an explicit cursor in the declarative part of any PL/SQL block, subprogram, or package. You must declare explicit cursors for queries that return more than one row.
SQL cursors are managed automatically by PL/SQL. You need not write code to handle these cursors. However, you can track information about the execution of an SQL cursor through its attributes.
SQL cursor attributes return information about the execution of DML and DDL statements, such
ROLLBACK statements. The cursor attributes are
%ROWCOUNT. The values of the cursor attributes always refer to the most recently executed SQL statement. Before the database opens the
SQL cursor, its attributes yield
SQL cursor has another attribute,
%BULK_ROWCOUNT, designed for use with the
FORALL statement. For more information, see Counting Rows Affected by FORALL (%BULK_ROWCOUNT Attribute).
Until a SQL data manipulation statement is executed,
TRUE if an
DELETE statement affected one or more rows, or a
INTO statement returned one or more rows. Otherwise,
FALSE. In Example 6-7, you use
%FOUND to insert a row if a delete succeeds.
%NOTFOUND is the logical opposite of
TRUE if an
DELETE statement affected no rows, or a
INTO statement returned no rows. Otherwise,
%ROWCOUNT yields the number of rows affected by an
DELETE statement, or returned by a
0 if an
DELETE statement affected no rows, or a
INTO statement returned no rows. In Example 6-8,
%ROWCOUNT returns the number of rows that were deleted.
CREATE TABLE employees_temp AS SELECT * FROM employees; DECLARE mgr_no NUMBER(6) := 122; BEGIN DELETE FROM employees_temp WHERE manager_id = mgr_no; DBMS_OUTPUT.PUT_LINE ('Number of employees deleted: ' || TO_CHAR(SQL%ROWCOUNT)); END; /
INTO statement returns more than one row, PL/SQL raises the predefined exception
%ROWCOUNT yields 1, not the actual number of rows that satisfy the query.
The value of the
SQL%ROWCOUNT attribute refers to the most recently executed SQL statement from PL/SQL. To save an attribute value for later use, assign it to a local variable immediately.
SQL%ROWCOUNT attribute is not related to the state of a transaction. When a rollback to a savepoint is performed, the value of
SQL%ROWCOUNT is not restored to the old value before the savepoint was taken. Also, when an autonomous transaction is exited,
SQL%ROWCOUNT is not restored to the original value in the parent transaction.
The values of the cursor attributes always refer to the most recently executed SQL statement, wherever that statement is. It might be in a different scope (for example, in a sub-block). To save an attribute value for later use, assign it to a local variable immediately. Doing other operations, such as subprogram calls, might change the value of the variable before you can test it.
%NOTFOUND attribute is not useful in combination with the
INTO statement fails to return a row, PL/SQL raises the predefined exception
NO_DATA_FOUND immediately, interrupting the flow of control before you can check
INTO statement that invokes a SQL aggregate function always returns a value or a null. After such a statement, the
%NOTFOUND attribute is always
FALSE, so checking it is unnecessary.
You use three statements to control a cursor:
CLOSE. First, you initialize the cursor with the
OPEN statement, which identifies the result set. Then, you can execute
FETCH repeatedly until all rows have been retrieved, or you can use the
COLLECT clause to fetch all rows at once. When the last row has been processed, you release the cursor with the
This technique requires more code than other techniques such as the SQL cursor FOR loop. Its advantage is flexibility. You can:
Process several queries in parallel by declaring and opening multiple cursors.
Process multiple rows in a single loop iteration, skip rows, or split the processing into more than one loop.
You must declare a cursor before referencing it in other statements. You give the cursor a name and associate it with a specific query. You can optionally declare a return type for the cursor, such as
%ROWTYPE. You can optionally specify parameters that you use in the
WHERE clause instead of referring to local variables. These parameters can have default values. Example 6-9 shows how you can declare cursors.
Note:An explicit cursor declared in a package specification is affected by the
AUTHIDclause of the package. For more information, see "CREATE PACKAGE Statement".
DECLARE my_emp_id NUMBER(6); -- variable for employee_id my_job_id VARCHAR2(10); -- variable for job_id my_sal NUMBER(8,2); -- variable for salary CURSOR c1 IS SELECT employee_id, job_id, salary FROM employees WHERE salary > 2000; my_dept departments%ROWTYPE; -- variable for departments row CURSOR c2 RETURN departments%ROWTYPE IS SELECT * FROM departments WHERE department_id = 110;
The cursor is not a PL/SQL variable: you cannot assign a value to a cursor or use it in an expression. Cursors and variables follow the same scoping rules. Naming cursors after database tables is possible but not recommended.
A cursor can take parameters, which can appear in the associated query wherever constants can appear. The formal parameters of a cursor must be
IN parameters; they supply values in the query, but do not return any values from the query. You cannot impose the constraint
NULL on a cursor parameter.
As the following example shows, you can initialize cursor parameters to default values. You can pass different numbers of actual parameters to a cursor, accepting or overriding the default values as you please. Also, you can add new formal parameters without having to change existing references to the cursor.
DECLARE CURSOR c1 (low NUMBER DEFAULT 0, high NUMBER DEFAULT 99) IS SELECT * FROM departments WHERE department_id > low AND department_id < high;
Opening the cursor executes the query and identifies the result set, which consists of all rows that meet the query search criteria. For cursors declared using the
UPDATE clause, the
OPEN statement also locks those rows. An example of the
OPEN statement follows:
DECLARE CURSOR c1 IS SELECT employee_id, last_name, job_id, salary FROM employees WHERE salary > 2000; BEGIN OPEN c1;
Rows in the result set are retrieved by the
FETCH statement, not when the
OPEN statement is executed.
Unless you use the
COLLECT clause, explained in Fetching with a Cursor, the
FETCH statement retrieves the rows in the result set one at a time. Each fetch retrieves the current row and advances the cursor to the next row in the result set. You can store each column in a separate variable, or store the entire row in a record that has the appropriate fields, usually declared using
For each column value returned by the query associated with the cursor, there must be a corresponding, type-compatible variable in the
INTO list. Typically, you use the
FETCH statement with a
NOTFOUND statements, as shown in Example 6-10. Note the use of built-in regular expression functions in the queries.
DECLARE v_jobid employees.job_id%TYPE; -- variable for job_id v_lastname employees.last_name%TYPE; -- variable for last_name CURSOR c1 IS SELECT last_name, job_id FROM employees WHERE REGEXP_LIKE (job_id, 'S[HT]_CLERK'); v_employees employees%ROWTYPE; -- record variable for row CURSOR c2 is SELECT * FROM employees WHERE REGEXP_LIKE (job_id, '[ACADFIMKSA]_M[ANGR]'); BEGIN OPEN c1; -- open the cursor before fetching LOOP -- Fetches 2 columns into variables FETCH c1 INTO v_lastname, v_jobid; EXIT WHEN c1%NOTFOUND; DBMS_OUTPUT.PUT_LINE( RPAD(v_lastname, 25, ' ') || v_jobid ); END LOOP; CLOSE c1; DBMS_OUTPUT.PUT_LINE( '-------------------------------------' ); OPEN c2; LOOP -- Fetches entire row into the v_employees record FETCH c2 INTO v_employees; EXIT WHEN c2%NOTFOUND; DBMS_OUTPUT.PUT_LINE( RPAD(v_employees.last_name, 25, ' ') || v_employees.job_id ); END LOOP; CLOSE c2; END; /
The query can reference PL/SQL variables within its scope. Any variables in the query are evaluated only when the cursor is opened. In Example 6-11, each retrieved salary is multiplied by 2, even though
factor is incremented after every fetch.
DECLARE my_sal employees.salary%TYPE; my_job employees.job_id%TYPE; factor INTEGER := 2; CURSOR c1 IS SELECT factor*salary FROM employees WHERE job_id = my_job; BEGIN OPEN c1; -- factor initially equals 2 LOOP FETCH c1 INTO my_sal; EXIT WHEN c1%NOTFOUND; factor := factor + 1; -- does not affect FETCH END LOOP; CLOSE c1; END; /
To change the result set or the values of variables in the query, you must close and reopen the cursor with the input variables set to their new values. However, you can use a different
INTO list on separate fetches with the same cursor. Each fetch retrieves another row and assigns values to the target variables, as shown inExample 6-12.
DECLARE CURSOR c1 IS SELECT last_name FROM employees ORDER BY last_name; name1 employees.last_name%TYPE; name2 employees.last_name%TYPE; name3 employees.last_name%TYPE; BEGIN OPEN c1; FETCH c1 INTO name1; -- this fetches first row FETCH c1 INTO name2; -- this fetches second row FETCH c1 INTO name3; -- this fetches third row CLOSE c1; END;/
If you fetch past the last row in the result set, the values of the target variables are undefined. Eventually, the
FETCH statement fails to return a row. When that happens, no exception is raised. To detect the failure, use the cursor attribute
%NOTFOUND. For more information, see Using Cursor Expressions.
COLLECT clause lets you fetch all rows from the result set at once. See Retrieving Query Results into Collections (BULK COLLECT Clause). In Example 6-13, you bulk-fetch from a cursor into two collections.
DECLARE TYPE IdsTab IS TABLE OF employees.employee_id%TYPE; TYPE NameTab IS TABLE OF employees.last_name%TYPE; ids IdsTab; names NameTab; CURSOR c1 IS SELECT employee_id, last_name; FROM employees WHERE job_id = 'ST_CLERK'; BEGIN OPEN c1; FETCH c1 BULK COLLECT INTO ids, names; CLOsE c1; -- Here is where you process the elements in the collections FOR i IN ids.FIRST .. ids.LAST LOOP IF ids(i) > 140 THEN DBMS_OUTPUT.PUT_LINE( ids(i) ); END IF; END LOOP; FOR i IN names.FIRST .. names.LAST LOOP IF names(i) LIKE '%Ma%' THEN DBMS_OUTPUT.PUT_LINE( names(i) ); END IF; END LOOP; END; /
CLOSE statement disables the cursor, and the result set becomes undefined. Once a cursor is closed, you can reopen it, which runs the query again with the latest values of any cursor parameters and variables referenced in the
WHERE clause. Any other operation on a closed cursor raises the predefined exception
Every explicit cursor and cursor variable has four attributes:
%ROWCOUNT. When appended to the cursor or cursor variable name, these attributes return useful information about the execution of a SQL statement. You can use cursor attributes in procedural statements but not in SQL statements.
Explicit cursor attributes return information about the execution of a multiple-row query. When an explicit cursor or a cursor variable is opened, the rows that satisfy the associated query are identified and form the result set. Rows are fetched from the result set.
After a cursor or cursor variable is opened but before the first fetch,
NULL. After any fetches, it returns
TRUE if the last fetch returned a row, or
FALSE if the last fetch did not return a row. Example 6-14 uses
%FOUND to select an action.
DECLARE CURSOR c1 IS SELECT last_name, salary FROM employees WHERE ROWNUM < 11; my_ename employees.last_name%TYPE; my_salary employees.salary%TYPE; BEGIN OPEN c1; LOOP FETCH c1 INTO my_ename, my_salary; IF c1%FOUND THEN -- fetch succeeded DBMS_OUTPUT.PUT_LINE('Name = ' || my_ename || ', salary = ' || my_salary); ELSE -- fetch failed, so exit loop EXIT; END IF; END LOOP; END; /
If a cursor or cursor variable is not open, referencing it with
%FOUND raises the predefined exception
TRUE if its cursor or cursor variable is open; otherwise,
FALSE. Example 6-15 uses
%ISOPEN to select an action.
DECLARE CURSOR c1 IS SELECT last_name, salary FROM employees WHERE ROWNUM < 11; the_name employees.last_name%TYPE; the_salary employees.salary%TYPE; BEGIN IF c1%ISOPEN = FALSE THEN -- cursor was not already open OPEN c1; END IF; FETCH c1 INTO the_name, the_salary; CLOSE c1; END; /
%NOTFOUND is the logical opposite of
FALSE if the last fetch returned a row, or
TRUE if the last fetch failed to return a row. In Example 6-16, you use
%NOTFOUND to exit a loop when
FETCH fails to return a row.
DECLARE CURSOR c1 IS SELECT last_name, salary FROM employees WHERE ROWNUM < 11; my_ename employees.last_name%TYPE; my_salary employees.salary%TYPE; BEGIN OPEN c1; LOOP FETCH c1 INTO my_ename, my_salary; IF c1%NOTFOUND THEN -- fetch failed, so exit loop -- Another form of this test is -- "EXIT WHEN c1%NOTFOUND OR c1%NOTFOUND IS NULL;" EXIT; ELSE -- fetch succeeded DBMS_OUTPUT.PUT_LINE ('Name = ' || my_ename || ', salary = ' || my_salary); END IF; END LOOP; END; /
Before the first fetch,
FETCH never executes successfully, the loop is never exited, because the
WHEN statement executes only if its
WHEN condition is true. To be safe, you might want to use the following
EXIT statement instead:
EXIT WHEN c1%NOTFOUND OR c1%NOTFOUND IS NULL;
If a cursor or cursor variable is not open, referencing it with
%NOTFOUND raises an
When its cursor or cursor variable is opened,
%ROWCOUNT is zeroed. Before the first fetch,
%ROWCOUNT yields zero. Thereafter, it yields the number of rows fetched so far. The number is incremented if the last fetch returned a row. Example 6-17 uses
%ROWCOUNT to test if more than ten rows were fetched.
DECLARE CURSOR c1 IS SELECT last_name FROM employees WHERE ROWNUM < 11; name employees.last_name%TYPE; BEGIN OPEN c1; LOOP FETCH c1 INTO name; EXIT WHEN c1%NOTFOUND OR c1%NOTFOUND IS NULL; DBMS_OUTPUT.PUT_LINE(c1%ROWCOUNT || '. ' || name); IF c1%ROWCOUNT = 5 THEN DBMS_OUTPUT.PUT_LINE('--- Fetched 5th record ---'); END IF; END LOOP; CLOSE c1; END; /
If a cursor or cursor variable is not open, referencing it with
Table 6-1 shows the value of each cursor attribute before and after
CLOSE statements execute.
|Point in Time||%FOUND Value||%ISOPEN Value||%NOTFOUND Value||%ROWCOUNT Value|
Before each successive
After each successive
In Table 6-1:
%ROWCOUNT before a cursor is opened or after it is closed raises
After the first
FETCH, if the result set was empty,
%ROWCOUNT yields 0.
PL/SQL lets you perform queries and access individual fields or entire rows from the result set. In traditional database programming, you process query results using an internal data structure called a cursor. In most situations, PL/SQL can manage the cursor for you, so that code to process query results is straightforward and compact. This section explains how to process both simple queries where PL/SQL manages everything, and complex queries where you interact with the cursor.
If the query might return more than one row, but you do not care about values after the first, you can restrict any result set to a single row by comparing the
ROWNUM value. If the query might return no rows at all, use an exception handler to specify any actions to take when no data is found.
If you just want to check whether a condition exists in your data, you might be able to code the query with the
COUNT(*) operator, which always returns a number and never raises the
If you must bring a large quantity of data into local PL/SQL variables, rather than looping through a result set one row at a time, you can use the
COLLECT clause. When you query only certain columns, you can store all the results for each column in a separate collection variable. When you query all the columns of a table, you can store the entire result set in a collection of records, which makes it convenient to loop through the results and refer to different columns. See Example 6-13, "Fetching Bulk Data with a Cursor".
This technique can be very fast, but also very memory-intensive. If you use it often, you might be able to improve your code by doing more of the work in SQL:
If you must loop only once through the result set, use a
FOR loop as described in the following sections. This technique avoids the memory overhead of storing a copy of the result set.
If you are looping through the result set to scan for certain values or filter the results into a smaller set, do this scanning or filtering in the original query instead. You can add more
WHERE clauses in simple cases, or use set operators such as
MINUS if you are comparing two or more sets of results.
If you are looping through the result set and running another query or a DML statement for each result row, you can probably find a more efficient technique. For queries, look at including subqueries or
EXISTS clauses in the original query. For DML statements, look at the
FORALL statement, which is much faster than coding these statements inside a regular loop.
Perhaps the most common case of a query is one where you issue the
SELECT statement, then immediately loop once through the rows of the result set. PL/SQL lets you use a simple
FOR loop for this kind of query.
The iterator variable for the
FOR loop does need not be declared in advance. It is a
%ROWTYPE record whose field names match the column names from the query, and that exists only during the loop. When you use expressions rather than explicit column names, use column aliases so that you can refer to the corresponding values inside the loop.
You might want to specify a query in one place but retrieve the rows somewhere else, even in another subprogram. Or you might want to choose very different query parameters, such as
BY clauses, depending on the situation. Or you might want to process some rows differently than others, and so need more than a simple loop.
Because explicit cursors are so flexible, you can choose from different notations depending on your needs. The following sections describe all the query-processing features that explicit cursors provide.
You include the text of the query directly in the
PL/SQL creates a record variable with fields corresponding to the columns of the result set.
You refer to the fields of this record variable inside the loop. You can perform tests and calculations, display output, or store the results somewhere else.
Here is an example that you can run in SQL*Plus. It does a query to get the name and job Id of employees with manager Ids greater than 120.
BEGIN FOR item IN ( SELECT last_name, job_id FROM employees WHERE job_id LIKE '%CLERK%' AND manager_id > 120 ) LOOP DBMS_OUTPUT.PUT_LINE ('Name = ' || item.last_name || ', Job = ' || item.job_id); END LOOP; END; /
Before each iteration of the
FOR loop, PL/SQL fetches into the implicitly declared record. The sequence of statements inside the loop is executed once for each row that satisfies the query. When you leave the loop, the cursor is closed automatically. The cursor is closed even if you use an
GOTO statement to leave the loop before all rows are fetched, or an exception is raised inside the loop. See LOOP Statements.
DECLARE CURSOR c1 IS SELECT last_name, job_id FROM employees WHERE job_id LIKE '%CLERK%' AND manager_id > 120; BEGIN FOR item IN c1 LOOP DBMS_OUTPUT.PUT_LINE ('Name = ' || item.last_name || ', Job = ' || item.job_id); END LOOP; END; /
In a cursor FOR loop, PL/SQL creates a
%ROWTYPE record with fields corresponding to columns in the result set. The fields have the same names as corresponding columns in the
The select list might contain an expression, such as a column plus a constant, or two columns concatenated together. If so, use a column alias to give unique names to the appropriate columns.
In Example 6-18,
dream_salary are aliases for expressions in the query.
A subquery is a query (usually enclosed in parentheses) that appears within another SQL data manipulation statement. The statement acts upon the single value or set of values returned by the subquery. For example:
You can use a subquery to find the
AVG value for a column, and use that single value in a comparison in a
You can use a subquery to find a set of values, and use this values in an
IN comparison in a
WHERE clause. This technique can avoid joins.
You can filter a set of values with a subquery, and apply other operations like
BY in the outer query.
You can use a subquery in place of a table name, in the
FROM clause of a query. This technique lets you join a table with a small set of rows from another table, instead of joining the entire tables.
You can create a table or insert into a table, using a set of rows defined by a subquery.
Example 6-19 is illustrates two subqueries used in cursor declarations.
DECLARE CURSOR c1 IS -- main query returns only rows -- where the salary is greater than the average SELECT employee_id, last_name FROM employees WHERE salary > (SELECT AVG(salary) FROM employees); CURSOR c2 IS -- subquery returns all the rows in descending order of salary -- main query returns just the top 10 highest-paid employees SELECT * FROM (SELECT last_name, salary) FROM employees ORDER BY salary DESC, last_name) ORDER BY salary DESC, last_name) WHERE ROWNUM < 11; BEGIN FOR person IN c1 LOOP DBMS_OUTPUT.PUT_LINE ('Above-average salary: ' || person.last_name); END LOOP; FOR person IN c2 LOOP DBMS_OUTPUT.PUT_LINE ('Highest paid: ' || person.last_name || ' $' || person.salary); END LOOP; -- subquery identifies a set of rows -- to use with CREATE TABLE or INSERT END; /
Using a subquery in the
FROM clause, the query in Example 6-20 returns the number and name of each department with five or more employees.
DECLARE CURSOR c1 IS SELECT t1.department_id, department_name, staff FROM departments t1, ( SELECT department_id, COUNT(*) as staff FROM employees GROUP BY department_id) t2 WHERE t1.department_id = t2.department_id AND staff >= 5; BEGIN FOR dept IN c1 LOOP DBMS_OUTPUT.PUT_LINE ('Department = ' || dept.department_name || ', staff = ' || dept.staff); END LOOP; END; /
While a subquery is evaluated only once for each table, a correlated subquery is evaluated once for each row. Example 6-21 returns the name and salary of each employee whose salary exceeds the departmental average. For each row in the table, the correlated subquery computes the average salary for the corresponding department.
DECLARE -- For each department, find the average salary. -- Then find all the employees in -- that department making more than that average salary. CURSOR c1 IS SELECT department_id, last_name, salary FROM employees t WHERE salary > ( SELECT AVG(salary) FROM employees WHERE t.department_id = department_id ) ORDER BY department_id; BEGIN FOR person IN c1 LOOP DBMS_OUTPUT.PUT_LINE('Making above-average salary = ' || person.last_name); END LOOP; END; /
Instead of referring to local variables, you can declare a cursor that accepts parameters, and pass values for those parameters when you open the cursor. If the query is usually issued with certain values, you can make those values the defaults. You can use either positional notation or named notation to pass the parameter values.
Example 6-22 displays the wages paid to employees earning over a specified wage in a specified department.
DECLARE CURSOR c1 (job VARCHAR2, max_wage NUMBER) IS SELECT * FROM employees WHERE job_id = job AND salary > max_wage; BEGIN FOR person IN c1('CLERK', 3000) LOOP -- process data record DBMS_OUTPUT.PUT_LINE ('Name = ' || person.last_name || ', salary = ' || person.salary || ', Job Id = ' || person.job_id ); END LOOP; END; /
In Example 6-23, several ways are shown to open a cursor.
DECLARE emp_job employees.job_id%TYPE := 'ST_CLERK'; emp_salary employees.salary%TYPE := 3000; my_record employees%ROWTYPE; CURSOR c1 (job VARCHAR2, max_wage NUMBER) IS SELECT * FROM employees WHERE job_id = job AND salary > max_wage; BEGIN -- Any of the following statements opens the cursor: -- OPEN c1('ST_CLERK', 3000); OPEN c1('ST_CLERK', emp_salary); -- OPEN c1(emp_job, 3000); OPEN c1(emp_job, emp_salary); OPEN c1(emp_job, emp_salary); LOOP FETCH c1 INTO my_record; EXIT WHEN c1%NOTFOUND; -- process data record DBMS_OUTPUT.PUT_LINE ('Name = ' || my_record.last_name || ', salary = ' || my_record.salary || ', Job Id = ' || my_record.job_id ); END LOOP; END; /
To avoid confusion, use different names for cursor parameters and the PL/SQL variables that you pass into those parameters.
A formal parameter declared with a default value does not need a corresponding actual parameter. If you omit the actual parameter, the formal parameter assumes its default value when the
OPEN statement executes. If the default value of a formal parameter is an expression, and you provide a corresponding actual parameter in the
OPEN statement, the expression is not evaluated.
Like a cursor, a cursor variable points to the current row in the result set of a multiple-row query. A cursor variable is more flexible because it is not tied to a specific query. You can open a cursor variable for any query that returns the right set of columns.
You pass a cursor variable as a parameter to local and stored subprograms. Opening the cursor variable in one subprogram, and processing it in a different subprogram, helps to centralize data retrieval. This technique is also useful for multi-language applications, where a PL/SQL subprogram might return a result set to a subprogram written in a different language, such as Java or Visual Basic.
Cursor variables are available to every PL/SQL client. For example, you can declare a cursor variable in a PL/SQL host environment such as an OCI or Pro*C program, then pass it as an input host variable (bind variable) to PL/SQL. Application development tools such as Oracle Forms, which have a PL/SQL engine, can use cursor variables entirely on the client side. Or, you can pass cursor variables back and forth between a client and the database server through remote subprogram calls.
Cursor variables are like pointers to result sets. You use them when you want to perform a query in one subprogram, and process the results in a different subprogram (possibly one written in a different language). A cursor variable has data type
CURSOR, and you might see them referred to informally as
Unlike an explicit cursor, which always refers to the same query work area, a cursor variable can refer to different work areas. You cannot use a cursor variable where a cursor is expected, or vice versa.
You use cursor variables to pass query result sets between PL/SQL stored subprograms and various clients. PL/SQL and its clients share a pointer to the query work area in which the result set is stored. For example, an OCI client, Oracle Forms application, and the database can all refer to the same work area.
A query work area remains accessible as long as any cursor variable points to it, as you pass the value of a cursor variable from one scope to another. For example, if you pass a host cursor variable to a PL/SQL block embedded in a Pro*C program, the work area to which the cursor variable points remains accessible after the block completes.
If you have a PL/SQL engine on the client side, calls from client to server impose no restrictions. For example, you can declare a cursor variable on the client side, open and fetch from it on the server side, then continue to fetch from it back on the client side. You can also reduce network traffic by having a PL/SQL block open or close several host cursor variables in a single round trip.
To create cursor variables, you define a
CURSOR type, then declare cursor variables of that type. You can define
CURSOR types in any PL/SQL block, subprogram, or package. In the following example, you declare a
REF CURSOR type that represents a result set from the
DECLARE TYPE DeptCurTyp IS REF CURSOR RETURN departments%ROWTYPE
CURSOR types can be strong (with a return type) or weak (with no return type). Strong
CURSOR types are less error prone because the PL/SQL compiler lets you associate a strongly typed cursor variable only with queries that return the right set of columns. Weak
CURSOR types are more flexible because the compiler lets you associate a weakly typed cursor variable with any query. Because there is no type checking with a weak
CURSOR, all such types are interchangeable. Instead of creating a new type, you can use the predefined type
DECLARE -- Strong: TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; -- Weak: TYPE genericcurtyp IS REF CURSOR; cursor1 empcurtyp; cursor2 genericcurtyp; my_cursor SYS_REFCURSOR; -- no new type needed TYPE deptcurtyp IS REF CURSOR RETURN departments%ROWTYPE; dept_cv deptcurtyp; -- declare cursor variable
To avoid declaring the same
CURSOR type in each subprogram that uses it, you can put the
CURSOR declaration in a package spec. You can declare cursor variables of that type in the corresponding package body, or within your own subprogram.
RETURN clause of a
CURSOR type definition, you can use
%ROWTYPE to refer to a strongly typed cursor variable, as shown in Example 6-24.
DECLARE TYPE TmpCurTyp IS REF CURSOR RETURN employees%ROWTYPE; tmp_cv TmpCurTyp; -- declare cursor variable TYPE EmpCurTyp IS REF CURSOR RETURN tmp_cv%ROWTYPE; emp_cv EmpCurTyp; -- declare cursor variable
You can also use
%ROWTYPE to provide the data type of a record variable, as shown in Example 6-25.
DECLARE dept_rec departments%ROWTYPE; -- declare record variable TYPE DeptCurTyp IS REF CURSOR RETURN dept_rec%TYPE; dept_cv DeptCurTyp; -- declare cursor variable
Example 6-26 specifies a user-defined
RECORD type in the
You can declare cursor variables as the formal parameters of subprograms. Example 6-27 defines a
CURSOR type, then declares a cursor variable of that type as a formal parameter.
DECLARE TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; emp empcurtyp; -- after result set is built, -- process all the rows inside a single procedure -- rather than invoking a procedure for each row PROCEDURE process_emp_cv (emp_cv IN empcurtyp) IS person employees%ROWTYPE; BEGIN DBMS_OUTPUT.PUT_LINE('-----'); DBMS_OUTPUT.PUT_LINE ('Here are the names from the result set:'); LOOP FETCH emp_cv INTO person; EXIT WHEN emp_cv%NOTFOUND; DBMS_OUTPUT.PUT_LINE('Name = ' || person.first_name || ' ' || person.last_name); END LOOP; END; BEGIN -- First find 10 arbitrary employees. OPEN emp FOR SELECT * FROM employees WHERE ROWNUM < 11; process_emp_cv(emp); CLOSE emp; -- find employees matching a condition. OPEN emp FOR SELECT * FROM employees WHERE last_name LIKE 'R%'; process_emp_cv(emp); CLOSE emp; END; /
Like all pointers, cursor variables increase the possibility of parameter aliasing. See Overloading PL/SQL Subprogram Names.
You use three statements to control a cursor variable:
CLOSE. First, you
OPEN a cursor variable
FOR a multiple-row query. Then, you
FETCH rows from the result set. When all the rows are processed, you
CLOSE the cursor variable.
OPEN-FOR statement associates a cursor variable with a multiple-row query, executes the query, and identifies the result set. The cursor variable can be declared directly in PL/SQL, or in a PL/SQL host environment such as an OCI program. For the syntax of the
OPEN-FOR statement, see OPEN-FOR Statement.
SELECT statement for the query can be coded directly in the statement, or can be a string variable or string literal. When you use a string as the query, it can include placeholders for bind variables, and you specify the corresponding values with a USING clause.
This section explains the static SQL case, in which
select_statement is used. For the dynamic SQL case, in which
dynamic_string is used, see OPEN-FOR Statement.
Unlike cursors, cursor variables take no parameters. Instead, you can pass whole queries (not just parameters) to a cursor variable. The query can reference host variables and PL/SQL variables, parameters, and functions.
Example 6-28 opens a cursor variable. Notice that you can apply cursor attributes (
%ROWCOUNT) to a cursor variable.
DECLARE TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; emp_cv empcurtyp; BEGIN IF NOT emp_cv%ISOPEN THEN -- open cursor variable OPEN emp_cv FOR SELECT * FROM employees; END IF; CLOSE emp_cv; END; /
OPEN-FOR statements can open the same cursor variable for different queries. You need not close a cursor variable before reopening it. Consecutive
OPENs of a static cursor raise the predefined exception
CURSOR_ALREADY_OPEN. When you reopen a cursor variable for a different query, the previous query is lost.
Typically, you open a cursor variable by passing it to a stored subprogram that declares an
OUT parameter that is a cursor variable. In Example 6-29 the subprogram opens a cursor variable.
CREATE PACKAGE emp_data AS TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; PROCEDURE open_emp_cv (emp_cv IN OUT empcurtyp); END emp_data; / CREATE PACKAGE BODY emp_data AS PROCEDURE open_emp_cv (emp_cv IN OUT EmpCurTyp) IS BEGIN OPEN emp_cv FOR SELECT * FROM employees; END open_emp_cv; END emp_data; /
You can also use a standalone stored subprogram to open the cursor variable. Define the
CURSOR type in a package, then reference that type in the parameter declaration for the stored subprogram.
To centralize data retrieval, you can group type-compatible queries in a stored subprogram. In Example 6-30, the packaged subprogram declares a selector as one of its formal parameters. When invoked, the subprogram opens the cursor variable
emp_cv for the chosen query.
CREATE PACKAGE emp_data AS TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; PROCEDURE open_emp_cv (emp_cv IN OUT empcurtyp, choice INT); END emp_data; / CREATE PACKAGE BODY emp_data AS PROCEDURE open_emp_cv (emp_cv IN OUT empcurtyp, choice INT) IS BEGIN IF choice = 1 THEN OPEN emp_cv FOR SELECT * FROM employees WHERE commission_pct IS NOT NULL; ELSIF choice = 2 THEN OPEN emp_cv FOR SELECT * FROM employees WHERE salary > 2500; ELSIF choice = 3 THEN OPEN emp_cv FOR SELECT * FROM employees WHERE department_id = 100; END IF; END; END emp_data; /
For more flexibility, a stored subprogram can execute queries with different return types, shown in Example 6-31.
CREATE PACKAGE admin_data AS TYPE gencurtyp IS REF CURSOR; PROCEDURE open_cv (generic_cv IN OUT gencurtyp, choice INT); END admin_data; / CREATE PACKAGE BODY admin_data AS PROCEDURE open_cv (generic_cv IN OUT gencurtyp, choice INT) IS BEGIN IF choice = 1 THEN OPEN generic_cv FOR SELECT * FROM employees; ELSIF choice = 2 THEN OPEN generic_cv FOR SELECT * FROM departments; ELSIF choice = 3 THEN OPEN generic_cv FOR SELECT * FROM jobs; END IF; END; END admin_data; /
You can declare a cursor variable in a PL/SQL host environment such as an OCI or Pro*C program. To use the cursor variable, you must pass it as a host variable to PL/SQL. In the following Pro*C example, you pass a host cursor variable and selector to a PL/SQL block, which opens the cursor variable for the chosen query.
EXEC SQL BEGIN DECLARE SECTION; ... /* Declare host cursor variable. */ SQL_CURSOR generic_cv; int choice; EXEC SQL END DECLARE SECTION; ... /* Initialize host cursor variable. */ EXEC SQL ALLOCATE :generic_cv; ... /* Pass host cursor variable and selector to PL/SQL block. * / EXEC SQL EXECUTE BEGIN IF :choice = 1 THEN OPEN :generic_cv FOR SELECT * FROM employees; ELSIF :choice = 2 THEN OPEN :generic_cv FOR SELECT * FROM departments; ELSIF :choice = 3 THEN OPEN :generic_cv FOR SELECT * FROM jobs; END IF; END; END-EXEC;
Host cursor variables are compatible with any query return type. They act just like weakly typed PL/SQL cursor variables.
FETCH statement retrieves rows from the result set of a multiple-row query. It works the same with cursor variables as with explicit cursors. Example 6-32 fetches rows one at a time from a cursor variable into a record.
DECLARE TYPE empcurtyp IS REF CURSOR RETURN employees%ROWTYPE; emp_cv empcurtyp; emp_rec employees%ROWTYPE; BEGIN OPEN emp_cv FOR SELECT * FROM employees WHERE employee_id < 120; LOOP FETCH emp_cv INTO emp_rec; -- fetch from cursor variable EXIT WHEN emp_cv%NOTFOUND; -- exit when last row is fetched -- process data record DBMS_OUTPUT.PUT_LINE ('Name = ' || emp_rec.first_name || ' ' || emp_rec.last_name); END LOOP; CLOSE emp_cv; END; /
COLLECT clause, you can bulk fetch rows from a cursor variable into one or more collections as shown in Example 6-33.
DECLARE TYPE empcurtyp IS REF CURSOR; TYPE namelist IS TABLE OF employees.last_name%TYPE; TYPE sallist IS TABLE OF employees.salary%TYPE; emp_cv empcurtyp; names namelist; sals sallist; BEGIN OPEN emp_cv FOR SELECT last_name, salary FROM employees WHERE job_id = 'SA_REP'; FETCH emp_cv BULK COLLECT INTO names, sals; CLOSE emp_cv; -- loop through the names and sals collections FOR i IN names.FIRST .. names.LAST LOOP DBMS_OUTPUT.PUT_LINE ('Name = ' || names(i) || ', salary = ' || sals(i)); END LOOP; END; /
Any variables in the associated query are evaluated only when the cursor variable is opened. To change the result set or the values of variables in the query, reopen the cursor variable with the variables set to new values. You can use a different
INTO clause on separate fetches with the same cursor variable. Each fetch retrieves another row from the same result set.
PL/SQL makes sure the return type of the cursor variable is compatible with the
INTO clause of the
FETCH statement. If there is a mismatch, an error occurs at compile time if the cursor variable is strongly typed, or at run time if it is weakly typed. At run time, PL/SQL raises the predefined exception
ROWTYPE_MISMATCH before the first fetch. If you trap the error and execute the
FETCH statement using a different (compatible)
INTO clause, no rows are lost.
When you declare a cursor variable as the formal parameter of a subprogram that fetches from the cursor variable, you must specify the
OUT mode. If the subprogram also opens the cursor variable, you must specify the
If you try to fetch from a closed or never-opened cursor variable, PL/SQL raises the predefined exception
When declaring a cursor variable as the formal parameter of a subprogram that closes the cursor variable, you must specify the
OUT mode. If you try to close an already-closed or never-opened cursor variable, PL/SQL raises the predefined exception
When passing host cursor variables to PL/SQL, you can reduce network traffic by grouping
OPEN-FOR statements. For example, the following PL/SQL block opens multiple cursor variables in a single round trip:
/* anonymous PL/SQL block in host environment */ BEGIN OPEN :emp_cv FOR SELECT * FROM employees; OPEN :dept_cv FOR SELECT * FROM departments; OPEN :loc_cv FOR SELECT * FROM locations; END; /
This technique might be useful in Oracle Forms, for example, when you want to populate a multiblock form. When you pass host cursor variables to a PL/SQL block for opening, the query work areas to which they point remain accessible after the block completes, so your OCI or Pro*C program can use these work areas for ordinary cursor operations. For example, you open several such work areas in a single round trip:
BEGIN OPEN :c1 FOR SELECT 1 FROM DUAL; OPEN :c2 FOR SELECT 1 FROM DUAL; OPEN :c3 FOR SELECT 1 FROM DUAL; END; /
The cursors assigned to
c3 act normally, and you can use them for any purpose. When finished, release the cursors as follows:
BEGIN CLOSE :c1; CLOSE :c2; CLOSE :c3; END; /
If both cursor variables involved in an assignment are strongly typed, they must have exactly the same data type (not just the same return type). If one or both cursor variables are weakly typed, they can have different data types.
If you try to fetch from, close, or refer to cursor attributes of a cursor variable that does not point to a query work area, PL/SQL raises the
INVALID_CURSOR exception. You can make a cursor variable (or parameter) point to a query work area in two ways:
OPEN the cursor variable
FOR the query.
Assign to the cursor variable the value of an already opened host cursor variable or PL/SQL cursor variable.
If you assign an unopened cursor variable to another cursor variable, the second one remains invalid even after you open the first one.
Be careful when passing cursor variables as parameters. At run time, PL/SQL raises
ROWTYPE_MISMATCH if the return types of the actual and formal parameters are incompatible.
You cannot declare cursor variables in a package specification, as illustrated in Example 6-34.
If you bind a host cursor variable into PL/SQL from an OCI client, you cannot fetch from it on the server side unless you also open it there on the same server call.
You cannot use comparison operators to test cursor variables for equality, inequality, or nullity.
Database columns cannot store the values of cursor variables. There is no equivalent type to use in a
You cannot store cursor variables in an associative array, nested table, or varray.
Cursors and cursor variables are not interoperable; that is, you cannot use one where the other is expected. For example, you cannot reference a cursor variable in a cursor
CREATE PACKAGE emp_data AS TYPE EmpCurTyp IS REF CURSOR RETURN employees%ROWTYPE; -- emp_cv EmpCurTyp; -- not allowed PROCEDURE open_emp_cv; END emp_data; / CREATE PACKAGE BODY emp_data AS -- emp_cv EmpCurTyp; -- not allowed PROCEDURE open_emp_cv IS emp_cv EmpCurTyp; -- this is legal BEGIN OPEN emp_cv FOR SELECT * FROM employees; END open_emp_cv; END emp_data; /
CURSOR variable in a server-to-server RPC results in an error. However, a
CURSOR variable is permitted in a server-to-server RPC if the remote database is not an Oracle Database accessed through a Procedural Gateway.
LOB parameters are not permitted in a server-to-server RPC.
A cursor expression returns a nested cursor. Each row in the result set can contain values, as usual, and cursors produced by subqueries involving the other values in the row. A single query can return a large set of related values retrieved from multiple tables. You can process the result set with nested loops that fetch first from the rows of the result set, and then from any nested cursors within those rows.
PL/SQL supports queries with cursor expressions as part of cursor declarations,
CURSOR declarations and
CURSOR variables. (You can also use cursor expressions in dynamic SQL queries.)
The syntax of a cursor expression is:
A nested cursor is implicitly opened when the containing row is fetched from the parent cursor. The nested cursor is closed only when:
The nested cursor is explicitly closed by the user
The parent cursor is reexecuted
The parent cursor is closed
The parent cursor is canceled
An error arises during a fetch on one of its parent cursors. The nested cursor is closed as part of the clean-up.
In Example 6-35, the cursor
c1 is associated with a query that includes a cursor expression. For each department in the
departments table, the nested cursor returns the last name of each employee in that department (which it retrieves from the
DECLARE TYPE emp_cur_typ IS REF CURSOR; emp_cur emp_cur_typ; dept_name departments.department_name%TYPE; emp_name employees.last_name%TYPE; CURSOR c1 IS SELECT department_id, CURSOR (SELECT e.last_name FROM employees e WHERE e.department_id = d.department_id) employees FROM departments d WHERE department_name LIKE 'A%'; BEGIN OPEN c1; LOOP -- Process each row of query's result set FETCH c1 INTO dept_name, emp_cur; EXIT WHEN c1%NOTFOUND; DBMS_OUTPUT.PUT_LINE('Department: ' || dept_name); LOOP -- Process each row of subquery's result set -- (this could be done in a procedure instead) FETCH emp_cur INTO emp_name; EXIT WHEN emp_cur%NOTFOUND; DBMS_OUTPUT.PUT_LINE('-- Employee: ' || emp_name); END LOOP; END LOOP; CLOSE c1; END; /
If a function has a formal parameter of the type
CURSOR, the corresponding actual parameter can be a cursor expression. By using a cursor expression as an actual parameter, you can pass the function a set of rows as a parameter.
Cursor expressions are often used with pipelined table functions, which are explained in Performing Multiple Transformations with Pipelined Table Functions.
You cannot use a cursor expression with a SQL cursor.
Cursor expressions can appear only:
SELECT statement that is not nested in any other query expression, except when it is a subquery of the cursor expression itself.
As arguments to table functions, in the
FROM clause of a
Cursor expressions can appear only in the outermost
SELECT list of the query specification.
Cursor expressions cannot appear in view declarations.
You cannot perform
EXECUTE operations on cursor expressions.
This section explains transaction processing with PL/SQL using SQL
ROLLBACK statements that ensure the consistency of a database. You can include these SQL statements directly in your PL/SQL programs. Transaction processing is a database feature, available through all programming languages, that lets multiple users work on the database concurrently, and ensures that each user sees a consistent version of data and that all changes are applied in the right order.
You usually need not write extra code to prevent problems with multiple users accessing data concurrently. The database uses locks to control concurrent access to data, and locks only the minimum amount of data necessary, for as little time as possible. You can request locks on tables or rows if you really do need this level of control. You can choose from several modes of locking such as
Oracle Database Concepts for information about transactions
Oracle Database SQL Language Reference for information about the
Oracle Database SQL Language Reference for information about the
Oracle Database SQL Language Reference for information about the
COMMIT statement ends the current transaction, making any changes made during that transaction permanent, and visible to other users. Transactions are not tied to PL/SQL
BEGIN-END blocks. A block can contain multiple transactions, and a transaction can span multiple blocks.
Example 6-36 illustrates a transaction that transfers money from one bank account to another. It is important that the money come out of one account, and into the other, at exactly the same moment. Otherwise, a problem partway through might make the money be lost from both accounts or be duplicated in both accounts.
CREATE TABLE accounts (account_id NUMBER(6), balance NUMBER (10,2)); INSERT INTO accounts VALUES (7715, 6350.00); INSERT INTO accounts VALUES (7720, 5100.50); DECLARE transfer NUMBER(8,2) := 250; BEGIN UPDATE accounts SET balance = balance - transfer WHERE account_id = 7715; UPDATE accounts SET balance = balance + transfer WHERE account_id = 7720; COMMIT COMMENT 'Transfer from 7715 to 7720' WRITE IMMEDIATE NOWAIT; END; /
COMMENT clause lets you specify a comment to be associated with a distributed transaction. If a network or computer fails during the commit, the state of the distributed transaction might be unknown or in doubt. In that case, the database stores the text specified by
COMMENT in the data dictionary along with the transaction ID.
Asynchronous commit provides more control for the user with the
WRITE clause. This option specifies the priority with which the redo information generated by the commit operation is written to the redo log.
Oracle Database Advanced Application Developer's Guide for more information about committing transactions
Oracle Database Concepts for information about distributed transactions
Oracle Database SQL Language Referencefor information about the
ROLLBACK statement ends the current transaction and undoes any changes made during that transaction. If you make a mistake, such as deleting the wrong row from a table, a rollback restores the original data. If you cannot finish a transaction because an exception is raised or a SQL statement fails, a rollback lets you take corrective action and perhaps start over.
Example 6-37 inserts information about an employee into three different database tables. If an
INSERT statement tries to store a duplicate employee number, the predefined exception
DUP_VAL_ON_INDEX is raised. To make sure that changes to all three tables are undone, the exception handler executes a
CREATE TABLE emp_name AS SELECT employee_id, last_name FROM employees; CREATE UNIQUE INDEX empname_ix ON emp_name (employee_id); CREATE TABLE emp_sal AS SELECT employee_id, salary FROM employees; CREATE UNIQUE INDEX empsal_ix ON emp_sal (employee_id); CREATE TABLE emp_job AS SELECT employee_id, job_id FROM employees; CREATE UNIQUE INDEX empjobid_ix ON emp_job (employee_id); DECLARE emp_id NUMBER(6); emp_lastname VARCHAR2(25); emp_salary NUMBER(8,2); emp_jobid VARCHAR2(10); BEGIN SELECT employee_id, last_name, salary, job_id INTO emp_id, emp_lastname, emp_salary, emp_jobid FROM employees WHERE employee_id = 120; INSERT INTO emp_name VALUES (emp_id, emp_lastname); INSERT INTO emp_sal VALUES (emp_id, emp_salary); INSERT INTO emp_job VALUES (emp_id, emp_jobid); EXCEPTION WHEN DUP_VAL_ON_INDEX THEN ROLLBACK; DBMS_OUTPUT.PUT_LINE('Inserts were rolled back'); END; /
See Also:Oracle Database SQL Language Reference for more information about the
SAVEPOINT names and marks the current point in the processing of a transaction. Savepoints let you roll back part of a transaction instead of the whole transaction. The number of active savepoints for each session is unlimited.
Example 6-38 marks a savepoint before doing an insert. If the
INSERT statement tries to store a duplicate value in the
employee_id column, the predefined exception
DUP_VAL_ON_INDEX is raised. In that case, you roll back to the savepoint, undoing just the insert.
CREATE TABLE emp_name AS SELECT employee_id, last_name, salary FROM employees; CREATE UNIQUE INDEX empname_ix ON emp_name (employee_id); DECLARE emp_id employees.employee_id%TYPE; emp_lastname employees.last_name%TYPE; emp_salary employees.salary%TYPE; BEGIN SELECT employee_id, last_name, salary INTO emp_id, emp_lastname, emp_salary FROM employees WHERE employee_id = 120; UPDATE emp_name SET salary = salary * 1.1 WHERE employee_id = emp_id; DELETE FROM emp_name WHERE employee_id = 130; SAVEPOINT do_insert; INSERT INTO emp_name VALUES (emp_id, emp_lastname, emp_salary); EXCEPTION WHEN DUP_VAL_ON_INDEX THEN ROLLBACK TO do_insert; DBMS_OUTPUT.PUT_LINE('Insert was rolled back'); END; /
If you mark a savepoint within a recursive subprogram, new instances of the
SAVEPOINT statement are executed at each level in the recursive descent, but you can only roll back to the most recently marked savepoint.
Savepoint names are undeclared identifiers. reusing a savepoint name within a transaction moves the savepoint from its old position to the current point in the transaction. This means that a rollback to the savepoint affects only the current part of your transaction, as shown in Example 6-39.
CREATE TABLE emp_name AS SELECT employee_id, last_name, salary FROM employees; CREATE UNIQUE INDEX empname_ix ON emp_name (employee_id); DECLARE emp_id employees.employee_id%TYPE; emp_lastname employees.last_name%TYPE; emp_salary employees.salary%TYPE; BEGIN SELECT employee_id, last_name, salary INTO emp_id, emp_lastname, emp_salary FROM employees WHERE employee_id = 120; SAVEPOINT my_savepoint; UPDATE emp_name SET salary = salary * 1.1 WHERE employee_id = emp_id; DELETE FROM emp_name WHERE employee_id = 130; -- Move my_savepoint to current point SAVEPOINT my_savepoint; INSERT INTO emp_name VALUES (emp_id, emp_lastname, emp_salary); EXCEPTION WHEN DUP_VAL_ON_INDEX THEN ROLLBACK TO my_savepoint; DBMS_OUTPUT.PUT_LINE('Transaction rolled back.'); END; /
See Also:Oracle Database SQL Language Reference for more information about the
Before executing an
DELETE statement, the database marks an implicit savepoint (unavailable to you). If the statement fails, the database rolls back to the savepoint. Usually, just the failed SQL statement is rolled back, not the whole transaction. If the statement raises an unhandled exception, the host environment determines what is rolled back.
The database can also roll back single SQL statements to break deadlocks. The database signals an error to one of the participating transactions and rolls back the current statement in that transaction.
Before executing a SQL statement, the database must parse it, that is, examine it to make sure it follows syntax rules and refers to valid schema objects. Errors detected while executing a SQL statement cause a rollback, but errors detected while parsing the statement do not.
If you exit a stored subprogram with an unhandled exception, PL/SQL does not assign values to
OUT parameters, and does not do any rollback.
Explicitly commit or roll back every transaction. Whether you issue the commit or rollback in your PL/SQL program or from a client program depends on the application logic. If you do not commit or roll back a transaction explicitly, the client environment determines its final state.
For example, in the SQL*Plus environment, if your PL/SQL block does not include a
ROLLBACK statement, the final state of your transaction depends on what you do after running the block. If you execute a data definition, data control, or
COMMIT statement or if you issue the
QUIT statement, the database commits the transaction. If you execute a
ROLLBACK statement or stop the SQL*Plus session, the database rolls back the transaction.
You use the
TRANSACTION statement to begin a read-only or read/write transaction, establish an isolation level, or assign your current transaction to a specified rollback segment. Read-only transactions are useful for running multiple queries while other users update the same tables.
During a read-only transaction, all queries refer to the same snapshot of the database, providing a multi-table, multi-query, read-consistent view. Other users can continue to query or update data as usual. A commit or rollback ends the transaction. In Example 6-40 a store manager uses a read-only transaction to gather order totals for the day, the past week, and the past month. The totals are unaffected by other users updating the database during the transaction.
DECLARE daily_order_total NUMBER(12,2); weekly_order_total NUMBER(12,2); monthly_order_total NUMBER(12,2); BEGIN COMMIT; -- ends previous transaction SET TRANSACTION READ ONLY NAME 'Calculate Order Totals'; SELECT SUM (order_total) INTO daily_order_total FROM orders WHERE order_date = SYSDATE; SELECT SUM (order_total) INTO weekly_order_total FROM orders WHERE order_date = SYSDATE - 7; SELECT SUM (order_total) INTO monthly_order_total FROM orders WHERE order_date = SYSDATE - 30; COMMIT; -- ends read-only transaction END; /
TRANSACTION statement must be the first SQL statement in a read-only transaction and can only appear once in a transaction. If you set a transaction to
ONLY, subsequent queries see only changes committed before the transaction began. The use of
ONLY does not affect other users or transactions.
See Also:Oracle Database SQL Language Reference for more information about the SQL statement
By default, the database locks data structures for you automatically, which is a major strength of the database: different applications can read and write to the same data without harming each other's data or coordinating with each other.
You can request data locks on specific rows or entire tables if you must override default locking. Explicit locking lets you deny access to data for the duration of a transaction:
TABLE statement, you can explicitly lock entire tables.
UPDATE statement, you can explicitly lock specific rows of a table to make sure they do not change after you have read them. That way, you can check which or how many rows will be affected by an
DELETE statement before issuing the statement, and no other application can change the rows in the meantime.
DECLARE CURSOR c1 IS SELECT employee_id, salary FROM employees WHERE job_id = 'SA_REP' AND commission_pct > .10 FOR UPDATE NOWAIT;
UPDATE statement identifies the rows that will be updated or deleted, then locks each row in the result set. This is useful when you want to base an update on the existing values in a row. In that case, you must make sure the row is not changed by another user before the update.
The optional keyword
NOWAIT tells the database not to wait if requested rows have been locked by another user. Control is immediately returned to your program so that it can do other work before trying again to acquire the lock. If you omit the keyword
NOWAIT, the database waits until the rows are available.
All rows are locked when you open the cursor, not as they are fetched. The rows are unlocked when you commit or roll back the transaction. Since the rows are no longer locked, you cannot fetch from a
UPDATE cursor after a commit.
When querying multiple tables, you can use the
UPDATE clause to confine row locking to particular tables. Rows in a table are locked only if the
OF clause refers to a column in that table. For example, the following query locks rows in the
employees table but not in the
DECLARE CURSOR c1 IS SELECT last_name, department_name FROM employees, departments WHERE employees.department_id = departments.department_id AND job_id = 'SA_MAN' FOR UPDATE OF salary;
As shown in Example 6-41, you use the
OF clause in an
DELETE statement to refer to the latest row fetched from a cursor.
DECLARE my_emp_id NUMBER(6); my_job_id VARCHAR2(10); my_sal NUMBER(8,2); CURSOR c1 IS SELECT employee_id, job_id, salary FROM employees FOR UPDATE; BEGIN OPEN c1; LOOP FETCH c1 INTO my_emp_id, my_job_id, my_sal; IF my_job_id = 'SA_REP' THEN UPDATE employees SET salary = salary * 1.02 WHERE CURRENT OF c1; END IF; EXIT WHEN c1%NOTFOUND; END LOOP; END; /
You use the
TABLE statement to lock entire database tables in a specified lock mode so that you can share or deny access to them. Row share locks allow concurrent access to a table; they prevent other users from locking the entire table for exclusive use. Table locks are released when your transaction issues a commit or rollback.
LOCK TABLE employees IN ROW SHARE MODE NOWAIT;
The lock mode determines what other locks can be placed on the table. For example, many users can acquire row share locks on a table at the same time, but only one user at a time can acquire an exclusive lock. While one user has an exclusive lock on a table, no other users can insert, delete, or update rows in that table.
A table lock never keeps other users from querying a table, and a query never acquires a table lock. Only if two different transactions try to modify the same row will one transaction wait for the other to complete.
Oracle Database Advanced Application Developer's Guide for more information about lock modes
Oracle Database SQL Language Reference for more information about the
TABLE SQL statement
DECLARE -- if "FOR UPDATE OF salary" is included on following line, -- an exception is raised CURSOR c1 IS SELECT * FROM employees; emp_rec employees%ROWTYPE; BEGIN OPEN c1; LOOP -- FETCH fails on the second iteration with FOR UPDATE FETCH c1 INTO emp_rec; EXIT WHEN c1%NOTFOUND; IF emp_rec.employee_id = 105 THEN UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 105; END IF; COMMIT; -- releases locks END LOOP; END; /
If you want to fetch across commits, use the
ROWID pseudocolumn to mimic the
OF clause. Select the rowid of each row into a
UROWID variable, then use the rowid to identify the current row during subsequent updates and deletes.
DECLARE CURSOR c1 IS SELECT last_name, job_id, rowid FROM employees; my_lastname employees.last_name%TYPE; my_jobid employees.job_id%TYPE; my_rowid UROWID; BEGIN OPEN c1; LOOP FETCH c1 INTO my_lastname, my_jobid, my_rowid; EXIT WHEN c1%NOTFOUND; UPDATE employees SET salary = salary * 1.02 WHERE rowid = my_rowid; -- this mimics WHERE CURRENT OF c1 COMMIT; END LOOP; CLOSE c1; END; /
Because the fetched rows are not locked by a
UPDATE clause, other users might unintentionally overwrite your changes. The extra space needed for read consistency is not released until the cursor is closed, which can slow down processing for large updates.
The next example shows that you can use the
%ROWTYPE attribute with cursors that reference the
DECLARE CURSOR c1 IS SELECT employee_id, last_name, salary, rowid FROM employees; emp_rec c1%ROWTYPE; BEGIN OPEN c1; LOOP FETCH c1 INTO emp_rec; EXIT WHEN c1%NOTFOUND; IF emp_rec.salary = 0 THEN DELETE FROM employees WHERE rowid = emp_rec.rowid; END IF; END LOOP; CLOSE c1; END; /
An autonomous transaction is an independent transaction started by another transaction, the main transaction. Autonomous transactions do SQL operations and commit or roll back, without committing or rolling back the main transaction. For example, if you write auditing data to a log table, you want to commit the audit data even if the operation you are auditing later fails; if something goes wrong recording the audit data, you do not want the main operation to be rolled back.
Figure 6-1 shows how control flows from the main transaction (MT) to an autonomous transaction (AT) and back again.
Once started, an autonomous transaction is fully independent. It shares no locks, resources, or commit-dependencies with the main transaction. You can log events, increment retry counters, and so on, even if the main transaction rolls back.
More important, autonomous transactions help you build modular, reusable software components. You can encapsulate autonomous transactions within stored subprograms. A calling application needs not know whether operations done by that stored subprogram succeeded or failed.
To define autonomous transactions, you use the pragma (compiler directive)
AUTONOMOUS_TRANSACTION. The pragma instructs the PL/SQL compiler to mark a routine as autonomous (independent). In this context, the term routine includes:
Top-level (not nested) anonymous PL/SQL blocks
Local, standalone, and packaged subprograms
Methods of a SQL object type
You can code the pragma anywhere in the declarative section of a routine. But, for readability, code the pragma at the top of the section. The syntax is
Example 6-43 marks a packaged function as autonomous. You cannot use the pragma to mark all subprograms in a package (or all methods in an object type) as autonomous. Only individual routines can be marked autonomous.
CREATE OR REPLACE PACKAGE emp_actions AS -- package specification FUNCTION raise_salary (emp_id NUMBER, sal_raise NUMBER) RETURN NUMBER; END emp_actions; / CREATE OR REPLACE PACKAGE BODY emp_actions AS -- package body -- code for function raise_salary FUNCTION raise_salary (emp_id NUMBER, sal_raise NUMBER) RETURN NUMBER IS PRAGMA AUTONOMOUS_TRANSACTION; new_sal NUMBER(8,2); BEGIN UPDATE employees SET salary = salary + sal_raise WHERE employee_id = emp_id; COMMIT; SELECT salary INTO new_sal FROM employees WHERE employee_id = emp_id; RETURN new_sal; END raise_salary; END emp_actions; /
Example 6-44 marks a standalone subprogram as autonomous.
CREATE PROCEDURE lower_salary (emp_id NUMBER, amount NUMBER) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN UPDATE employees SET salary = salary - amount WHERE employee_id = emp_id; COMMIT; END lower_salary; /
Example 6-45 marks a PL/SQL block as autonomous. However, you cannot mark a nested PL/SQL block as autonomous.
DECLARE PRAGMA AUTONOMOUS_TRANSACTION; emp_id NUMBER(6); amount NUMBER(6,2); BEGIN emp_id := 200; amount := 200; UPDATE employees SET salary = salary - amount WHERE employee_id = emp_id; COMMIT; END; /
Example 6-46 marks a database trigger as autonomous. Unlike regular triggers, autonomous triggers can contain transaction control statements such as
CREATE TABLE emp_audit ( emp_audit_id NUMBER(6), up_date DATE, new_sal NUMBER(8,2), old_sal NUMBER(8,2) ); CREATE OR REPLACE TRIGGER audit_sal AFTER UPDATE OF salary ON employees FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN -- bind variables are used here for values INSERT INTO emp_audit VALUES( :old.employee_id, SYSDATE, :new.salary, :old.salary ); COMMIT; END; /
It does not share transactional resources (such as locks) with the main transaction.
It does not depend on the main transaction. For example, if the main transaction rolls back, nested transactions roll back, but autonomous transactions do not.
Its committed changes are visible to other transactions immediately. (A nested transaction's committed changes are not visible to other transactions until the main transaction commits.)
Exceptions raised in an autonomous transaction cause a transaction-level rollback, not a statement-level rollback.
The main transaction shares its context with nested routines, but not with autonomous transactions. When one autonomous routine invokes another (or itself, recursively), the routines share no transaction context. When an autonomous routine invokes a nonautonomous routine, the routines share the same transaction context.
Changes made by an autonomous transaction become visible to other transactions when the autonomous transaction commits. These changes become visible to the main transaction when it resumes, if its isolation level is set to
COMMITTED (the default).
If you set the isolation level of the main transaction to
SERIALIZABLE, changes made by its autonomous transactions are not visible to the main transaction when it resumes:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
The first SQL statement in an autonomous routine begins a transaction. When one transaction ends, the next SQL statement begins another transaction. All SQL statements executed since the last commit or rollback make up the current transaction. To control autonomous transactions, use the following statements, which apply only to the current (active) transaction:
Transaction properties set in the main transaction apply only to that transaction, not to its autonomous transactions, and vice versa.
Cursor attributes are not affected by autonomous transactions.
When you enter the executable section of an autonomous routine, the main transaction suspends. When you exit the routine, the main transaction resumes.
To exit normally, you must explicitly commit or roll back all autonomous transactions. If the routine (or any routine invoked by it) has pending transactions, an exception is raised, and the pending transactions are rolled back.
ROLLBACK end the active autonomous transaction but do not exit the autonomous routine. When one transaction ends, the next SQL statement begins another transaction. A single autonomous routine can contain several autonomous transactions, if it issues several
The scope of a savepoint is the transaction in which it is defined. Savepoints defined in the main transaction are unrelated to savepoints defined in its autonomous transactions. In fact, the main transaction and an autonomous transaction can use the same savepoint names.
You can roll back only to savepoints marked in the current transaction. In an autonomous transaction, you cannot roll back to a savepoint marked in the main transaction. To do so, you must resume the main transaction by exiting the autonomous routine.
When in the main transaction, rolling back to a savepoint marked before you started an autonomous transaction does not roll back the autonomous transaction. Remember, autonomous transactions are fully independent of the main transaction.
If an autonomous transaction attempts to access a resource held by the main transaction, a deadlock can occur. The database raises an exception in the autonomous transaction, which is rolled back if the exception goes unhandled.
The database initialization parameter
TRANSACTIONS specifies the maximum number of concurrent transactions. That number might be exceeded because an autonomous transaction runs concurrently with the main transaction.
If you try to exit an active autonomous transaction without committing or rolling back, the database raises an exception. If the exception goes unhandled, the transaction is rolled back.
Among other things, you can use database triggers to log events transparently. Suppose you want to track all inserts into a table, even those that roll back. In Example 6-47, you use a trigger to insert duplicate rows into a shadow table. Because it is autonomous, the trigger can commit changes to the shadow table whether or not you commit changes to the main table.
CREATE TABLE emp_audit ( emp_audit_id NUMBER(6), up_date DATE, new_sal NUMBER(8,2), old_sal NUMBER(8,2) ); -- create an autonomous trigger that inserts -- into the audit table before each update -- of salary in the employees table CREATE OR REPLACE TRIGGER audit_sal BEFORE UPDATE OF salary ON employees FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO emp_audit VALUES( :old.employee_id, SYSDATE, :new.salary, :old.salary ); COMMIT; END; / -- update the salary of an employee, and then commit the insert UPDATE employees SET salary salary * 1.05 WHERE employee_id = 115; COMMIT; -- update another salary, then roll back the update UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 116; ROLLBACK; -- show that both committed and rolled-back updates -- add rows to audit table SELECT * FROM emp_audit WHERE emp_audit_id = 115 OR emp_audit_id = 116;
Unlike regular triggers, autonomous triggers can execute DDL statements using native dynamic SQL, explained in Chapter 7, "Using Dynamic SQL." In the following example, trigger
drop_temp_table drops a temporary database table after a row is inserted in table
CREATE TABLE emp_audit ( emp_audit_id NUMBER(6), up_date DATE, new_sal NUMBER(8,2), old_sal NUMBER(8,2) ); CREATE TABLE temp_audit ( emp_audit_id NUMBER(6), up_date DATE); CREATE OR REPLACE TRIGGER drop_temp_table AFTER INSERT ON emp_audit DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE 'DROP TABLE temp_audit'; COMMIT; END; /
For more information about database triggers, see Chapter 9, "Using Triggers."
A function invoked from SQL statements must obey certain rules meant to control side effects. See Controlling Side Effects of PL/SQL Subprograms. To check for violations of the rules, you can use the pragma
RESTRICT_REFERENCES. The pragma asserts that a function does not read or write database tables or package variables. For more information, See Oracle Database Advanced Application Developer's Guide.
However, by definition, autonomous routines never violate the rules
(WNDS) no matter what they do. This can be useful, as Example 6-48 shows. When you invoke the packaged function
log_msg from a query, it inserts a message into database table
debug_output without violating the rule
-- create the debug table CREATE TABLE debug_output (msg VARCHAR2(200)); -- create the package spec CREATE PACKAGE debugging AS FUNCTION log_msg (msg VARCHAR2) RETURN VARCHAR2; PRAGMA RESTRICT_REFERENCES(log_msg, WNDS, RNDS); END debugging; / -- create the package body CREATE PACKAGE BODY debugging AS FUNCTION log_msg (msg VARCHAR2) RETURN VARCHAR2 IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN -- the following insert does not violate the constraint -- WNDS because this is an autonomous routine INSERT INTO debug_output VALUES (msg); COMMIT; RETURN msg; END; END debugging; / -- invoke the packaged function from a query DECLARE my_emp_id NUMBER(6); my_last_name VARCHAR2(25); my_count NUMBER; BEGIN my_emp_id := 120; SELECT debugging.log_msg(last_name) INTO my_last_name FROM employees WHERE employee_id = my_emp_id; -- even if you roll back in this scope, the insert into 'debug_output' remains -- committed because it is part of an autonomous transaction ROLLBACK; END; /