SET TRANSACTION

Purpose

For the current transaction, to:

• establish it as a read-only or read-write transaction
• establish the isolation level
• assign it to a specified rollback segment

The operations performed by a SET TRANSACTION statement affect only your current transaction, not other users or other transactions. Your transaction ends whenever you issue a COMMIT or ROLLBACK statement. Note also that Oracle implicitly commits the current transaction before and after executing a data definition language statement.

Prerequisites

If you use a SET TRANSACTION statement, it must be the first statement in your transaction. However, a transaction need not have a SET TRANSACTION statement.

Syntax

Keywords and Parameters

Establishing Read-Only Transactions

The default state for all transactions is statement-level read consistency. You can explicitly specify this state by issuing a SET TRANSACTION statement with the READ WRITE option.

You can establish transaction-level read consistency by issuing a SET TRANSACTION statement with the READ ONLY option. After a transaction has been established as read-only, all subsequent queries in that transaction only see changes committed before the transaction began. Read-only transactions are very useful for reports that run multiple queries against one or more tables while other users update these same tables.

Only the following statements are permitted in a read-only transaction:

• SELECT (but not statements with the FOR UPDATE clause)
• LOCK TABLE
• SET ROLE
• ALTER SESSION
• ALTER SYSTEM

INSERT, UPDATE, and DELETE statements and SELECT statements with the FOR UPDATE clause are not permitted. Any DDL statement implicitly ends the read-only transaction.

The read consistency that read-only transactions provide is implemented in the same way as statement-level read consistency. Every statement by default uses a consistent view of the data as of the time the statement is issued. Read-only transactions present a consistent view of the data as of the time that the SET TRANSACTION READ ONLY statement is issued. Read-only transactions provide read consistency is for all nodes accessed by distributed queries and local queries.

You cannot toggle between transaction-level read consistency and statement-level read consistency in the same transaction. A SET TRANSACTION statement can only be issued as the first statement of a transaction.

Example

The following statements could be run at midnight of the last day of every month to count how many ships and containers the company owns. This report would not be affected by any other user who might be adding or removing ships and/or containers.

COMMIT 
SET TRANSACTION READ ONLY 
SELECT COUNT(*) FROM ship 
SELECT COUNT(*) FROM container 
COMMIT; 

The last COMMIT statement does not actually make permanent any changes to the database. It simply ends the read-only transaction.

Assigning Transactions to Rollback Segments

If you issue a DML statement in a transaction, Oracle assigns the transaction to a rollback segment. The rollback segment holds the information necessary to undo the changes made by the transaction. You can issue a SET TRANSACTION statement with the USE ROLLBACK SEGMENT clause to choose a specific rollback segment for your transaction. If you do not choose a rollback segment, Oracle chooses one randomly and assigns your transaction to it.

SET TRANSACTION lets you to assign transactions of different types to rollback segments of different sizes:

• Assign OLTP transactions, or small transactions containing only a few DML statements that modify only a few rows, to small rollback segments if there are no long-running queries concurrently reading the same tables. Small rollback segments are more likely to remain in memory.
• Assign transactions that modify tables that are concurrently being read by long-running queries to large rollback segments so that the rollback information needed for the read-consistent queries is not overwritten.
• Assign transactions with bulk DML statements, or statements that insert, update, or delete large amounts of data, to rollback segments large enough to hold the rollback information for the transaction.

Example

The following statement assigns your current transaction to the rollback segment OLTP_5:

SET TRANSACTION USE ROLLBACK SEGMENT oltp_5;

Related Topics

COMMIT

ROLLBACK

SAVEPOINT

STORAGE clause

Purpose

To specify storage characteristics for tables, indexes, clusters, and rollback segments, and the default storage characteristics for tablespaces. See also "Specifying Storage Parameters".

Prerequisites

The STORAGE clause can appear in commands that create or alter any of the following schema objects:

• clusters
• indexes
• rollback segments
• snapshots
• snapshot logs
• tables
• tablespaces
• partitions

To change the value of a STORAGE parameter, you must have the privileges necessary to use the appropriate create or alter command.

Syntax

Keywords and Parameters

Specifying Storage Parameters

The storage parameters affect both how long it takes to access data stored in the database and how efficiently space in the database is used. For a discussion of the effects of these parameters, see Oracle8 Tuning.

When you create a tablespace, you can specify values for the storage parameters. These values serve as default values for segments allocated in the tablespace.

When you create a cluster, index, rollback segment, snapshot, snapshot log, or table, you can specify values for the storage parameters for the segments allocated to these objects. If you omit any storage parameter, Oracle uses the value of that parameter specified for the tablespace. However, when creating a rollback segment, you cannot specify PCTINCREASE (which is always 0) or MINEXTENTS (which is always 2).

When you alter a cluster, index, rollback segment, snapshot, snapshot log, or table, you can change the values of storage parameters. The new values only affect future extent allocations. For this reason, you cannot change the values of the INITIAL and MINEXTENTS parameter. If you change the value of the NEXT parameter, the next allocated extent will have the specified size, regardless of the size of the most recently allocated extent and the value of the PCTINCREASE parameter. If you change the value of the PCTINCREASE parameter, Oracle calculates the size of the next extent using this new value and the size of the most recently allocated extent.

When you alter a tablespace, you can change the values of storage parameters. The new values serve as default values only to subsequently allocated segments (or subsequently created objects).

Rollback Segments and MAXEXTENTS UNLIMITED

It is not good practice to create or alter a rollback segment to use MAXEXTENTS UNLIMITED. Rogue transactions containing inserts, updates, or deletes, that continue for a long time will continue to create new extents until a disk is full.

A rollback segment that you create without specifying the STORAGE option has the same storage parameters as the tablespace that the rollback segment is created in. Thus, if the tablespace is created with MAXEXTENT UNLIMITED, then the rollback segment would also have the same default.

Examples

Example I

The following statement creates a table and provides storage parameter values:

CREATE TABLE dept 
    (deptno     NUMBER(2), 
     dname      VARCHAR2(14), 
     loc        VARCHAR2(13) ) 
     STORAGE  ( INITIAL 100K  NEXT     50K 
                  MINEXTENTS 1  MAXEXTENTS 50  PCTINCREASE 5 ); 

Oracle allocates space for the table based on the STORAGE parameter values as follows:

• The MINEXTENTS value is 1, so Oracle allocates 1 extent for the table upon creation.
• The INITIAL value is 100K, so the first extent's size is 100 kilobytes.
• If the table data grows to exceed the first extent, Oracle allocates a second extent. The NEXT value is 50K, so the second extent's size would be 50 kilobytes.
• If the table data subsequently grows to exceed the first two extents, Oracle allocates a third extent. The PCTINCREASE value is 5, so the calculated size of the third extent is 5% larger than the second extent, or 52.5 kilobytes. If the data block size is 2 kilobytes, Oracle rounds this value to 52 kilobytes.

If the table data continues to grow, Oracle allocates more extents, each 5% larger than the previous one.

• The MAXEXTENTS value is 50, so Oracle can allocate as many as 50 extents for the table.

Example II

The following statement creates a rollback segment and provides storage parameter values:

CREATE ROLLBACK SEGMENT rsone 
    STORAGE ( INITIAL  10K  NEXT 10K 
              MINEXTENTS 2  MAXEXTENTS 25 
               OPTIMAL 50K ); 

Oracle allocates space for the rollback segment based on the STORAGE parameter values as follows:

• The MINEXTENTS value is 2, so Oracle allocates 2 extents for the rollback segment upon creation.
• The INITIAL value is 10K, so the first extent's size is 10 kilobytes.
• The NEXT value is 10K, so the second extent's size is 10 kilobytes.
• If the rollback data exceeds the first two extents, Oracle allocates a third extent. The PCTINCREASE value for rollback segments is always 0, so the third and subsequent extents are the same size as the second extent, 10 kilobytes.
• The MAXEXTENTS value is 25, so Oracle can allocate as many as 25 extents for the rollback segment.
• The OPTIMAL value is 50K, so Oracle deallocates extents if the rollback segment exceeds 50 kilobytes. Note that Oracle deallocates only extents that contain data for transactions that are no longer active.

Related Topics

CREATE CLUSTER

CREATE INDEX

CREATE ROLLBACK SEGMENT

CREATE TABLE

CREATE TABLESPACE

Subqueries

Purpose

A subquery is a form of the SELECT command that appears inside another SQL statement. A subquery is sometimes called a nested query. The statement containing a subquery is called the parent statement. The rows returned by the subquery are used by the parent statement. See also "Using Subqueries".

Syntax

WITH_clause::=

Keywords and Parameters

INSERT INTO (SELECT ename, deptno FROM emp
             WHERE deptno < 10)
       VALUES ('Taylor', 20);

INSERT INTO (SELECT ename, deptno FROM emp
             WHERE deptno < 10
               WITH CHECK OPTION)
       VALUES ('Taylor', 20);

Other keywords and parameters function as they are described in SELECT. For more information, see "Correlated Subqueries", "Selecting from the DUAL Table", "Using Sequences", and "Distributed Queries".

Using Subqueries

Use subqueries for the following purposes:

• to define the set of rows to be inserted into the target table of an INSERT or CREATE TABLE statement
• to define the set of rows to be included in a view or snapshot in a CREATE VIEW or CREATE SNAPSHOT statement
• to define one or more values to be assigned to existing rows in an UPDATE statement
• to provide values for conditions in WHERE, HAVING, and START WITH clauses of SELECT, UPDATE, and DELETE statements
• to define a table to be operated on by a containing query. You do this by placing the subquery in the FROM clause of the containing query as you would a table name. You may use subqueries in place of tables in this way as well in INSERT, UDPATE, and DELETE statements. Subqueries so used can employ correlation variables, but only those defined within the subquery itself, not outer references.

A subquery answers multiple-part questions. For example, to determine who works in Taylor's department, you can first use a subquery to determine the department in which Taylor works. You can then answer the original question with the parent SELECT statement.

A subquery is evaluated once for the entire parent statement, in contrast to a correlated subquery which is evaluated once per row processed by the parent statement.

A subquery can itself contain a subquery. Oracle places no limit on the level of query nesting.

Example I

To determine who works in Taylor's department, issue the following statement:

SELECT ename, deptno 
    FROM emp 
    WHERE deptno = 
        (SELECT deptno 
            FROM emp 
            WHERE ename = 'TAYLOR');

Example II

To give all employees in the EMP table a 10% raise if they have not already been issued a bonus (if they do not appear in the BONUS table), issue the following statement:

UPDATE emp 
    SET sal = sal * 1.1
    WHERE empno NOT IN (SELECT empno FROM bonus);

Example III

To create a duplicate of the DEPT table named NEWDEPT, issue the following statement:

CREATE TABLE newdept (deptno, dname, loc) 
    AS SELECT deptno, dname, loc FROM dept;

Using Flattened Subqueries

To manipulate the individual rows of a nested table stored in a database column, use the keyword THE. You must prefix THE to a subquery that returns a single column value or an expression that yields a nested table. If the subquery returns more than a single column value, a run-time error results. Because the value is a nested table, not a scalar value, Oracle must be informed, which is what THE does.

The following example adds a new row to department 40's nested table stored in column PROJECTS:

INSERT INTO 
  THE(SELECT projects FROM dept WHERE deptno = 40)
  VALUES(33, 'Install new email system', 14875); 

This example increases the budgets for two projects assigned to department 70:

UPDATE 
  THE(SELECT projects FROM dept WHERE deptno = 70) 
    SET budget = budget + 1000
    WHERE projno IN (24, 25);

Correlated Subqueries

A correlated subquery is a subquery that is evaluated once for each row processed by the parent statement. The parent statement can be a SELECT, UPDATE, or DELETE statement. The following examples show the general syntax of a correlated subquery:

SELECT select_list 
    FROM table1 t_alias1 
    WHERE expr operator 
        (SELECT column_list 
            FROM table2 t_alias2 
            WHERE t_alias1.column 
               operator t_alias2.column); 
UPDATE table1 t_alias1 
    SET column = 
        (SELECT expr 
            FROM table2 t_alias2 
            WHERE t_alias1.column = t_alias2.column); 
DELETE FROM table1 t_alias1 
    WHERE column operator 
        (SELECT expr 
            FROM table2 t_alias2 
            WHERE t_alias1.column = t_alias2.column); 

This discussion focuses on correlated subqueries in SELECT statements; it also applies to correlated subqueries in UPDATE and DELETE statements.

You can use a correlated subquery to answer a multiple-part question whose answer depends on the value in each row processed by the parent statement. For example, a correlated subquery can be used to determine which employees earn more than the average salaries for their departments. In this case, the correlated subquery specifically computes the average salary for each department.

Oracle performs a correlated subquery when the subquery references a column from a table from the parent statement.

Oracle resolves unqualified columns in the subquery by looking in the tables of the subquery, then in the tables of the parent statement, then in the tables of the next enclosing parent statement, and so on. Oracle resolves all unqualified columns in the subquery to the same table. If the tables in a subquery and parent query contain a column with the same name, a reference to the column of a table from the parent query must be prefixed by the table name or alias. To make your statements easier for you to read, always qualify the columns in a correlated subquery with the table, view, or snapshot name or alias.

In an UPDATE statement, you can use a correlated subquery to update rows in one table based on rows from another table. For example, you could use a correlated subquery to roll up four quarterly sales tables into a yearly sales table.

In a DELETE statement, you can use a correlated query to delete only those rows that also exist in another table.

Example

The following statement returns data about employees whose salaries exceed the averages for their departments. The following statement assigns an alias to EMP, the table containing the salary information, and then uses the alias in a correlated subquery:

SELECT deptno, ename, sal 
    FROM emp x 
    WHERE sal > (SELECT AVG(sal) 
          FROM emp 
          WHERE x.deptno = deptno) 
    ORDER BY deptno; 

For each row of the EMP table, the parent query uses the correlated subquery to compute the average salary for members of the same department. The correlated subquery performs these steps for each row of the EMP table:

1. The DEPTNO of the row is determined.
2. The DEPTNO is then used to evaluate the parent query.
3. If that row's salary is greater than the average salary for that row's department, then the row is returned.

The subquery is evaluated once for each row of the EMP table.

Selecting from the DUAL Table

DUAL is a table automatically created by Oracle along with the data dictionary. DUAL is in the schema of the user SYS, but is accessible by the name DUAL to all users. It has one column, DUMMY, defined to be VARCHAR2(1), and contains one row with a value 'X'. Selecting from the DUAL table is useful for computing a constant expression with the SELECT command. Because DUAL has only one row, the constant is returned only once. Alternatively, you can select a constant, pseudocolumn, or expression from any table.

Example

The following statement returns the current date:

SELECT SYSDATE FROM DUAL; 

You could select SYSDATE from the EMP table, but Oracle would return 14 rows of the same SYSDATE, one for every row of the EMP table. Selecting from DUAL is more convenient.

Using Sequences

The sequence pseudocolumns NEXTVAL and CURRVAL can also appear in the select list of a SELECT statement. For information on sequences and their use, see CREATE SEQUENCE and "Pseudocolumns".

Example

The following statement increments the ZSEQ sequence and returns the new value:

SELECT zseq.nextval 
    FROM dual; 

The following statement selects the current value of ZSEQ:

SELECT zseq.currval 
    FROM dual;

Distributed Queries

Oracle's distributed database management system architecture allows you to access data in remote databases using Net8 and an Oracle server. You can identify a remote table, view, or snapshot by appending @dblink to the end of its name. The dblink must be a complete or partial name for a database link to the database containing the remote table, view, or snapshot. For more information on referring to database links, see "Referring to Objects in Remote Databases".

Distributed queries are currently subject to the restriction that all tables locked by a FOR UPDATE clause and all tables with LONG columns selected by the query must be located on the same database. For example, the following statement will cause an error:

SELECT emp_ny.* 
    FROM emp_ny@ny, dept 
    WHERE emp_ny.deptno = dept.deptno 
    AND dept.dname = 'ACCOUNTING' 
    FOR UPDATE OF emp_ny.sal; 

The following statement fails because it selects LONG_COLUMN, a LONG value, from the EMP_REVIEW table on the NY database and locks the EMP table on the local database:

SELECT emp.empno, review.long_column, emp.sal 
    FROM emp, emp_review@ny review 
    WHERE emp.empno = emp_review.empno 
    FOR UPDATE OF emp.sal;

Example

This example shows a query that joins the DEPT table on the local database with the EMP table on the HOUSTON database:

SELECT ename, dname 
    FROM emp@houston, dept 
    WHERE emp.deptno = dept.deptno;

Related Topics

DELETE

SET CONSTRAINT(S)

UPDATE

TRUNCATE

Purpose

To remove all rows from a table or cluster and reset the STORAGE parameters to the values when the table or cluster was created. See also "Truncating Tables and Clusters". For illustrations, see "Examples".

Prerequisites

The table or cluster must be in your schema or you must have DROP ANY TABLE system privilege. See also "Restrictions".

Syntax

Keywords and Parameters

Truncating Tables and Clusters

You can use the TRUNCATE command to quickly remove all rows from a table or cluster. Removing rows with the TRUNCATE command is faster than removing them with the DELETE command for the following reasons:

• The TRUNCATE command is a data definition language (DDL) command and generates no rollback information.
• Truncating a table does not fire the table's DELETE triggers.

The TRUNCATE command allows you to optionally deallocate the space freed by the deleted rows. The DROP STORAGE option deallocates all but the space specified by the table's MINEXTENTS parameter.

Deleting rows with the TRUNCATE command is also more convenient than dropping and re-creating a table because dropping and re-creating:

• invalidates the table's dependent objects, while truncating does not
• requires you to regrant object privileges on the table, while truncating does not
• requires you to re-create the table's indexes, integrity constraints, and triggers and respecify its STORAGE parameters, while truncating does not

Note:   When you truncate a table, the storage parameter NEXT is changed to be the size of the last extent deleted from the segment in the process of truncation.

   

Restrictions

When you truncate a table, NEXT is automatically reset to the last extent deleted.

You cannot individually truncate a table that is part of a cluster. You must either truncate the cluster, delete all rows from the table, or drop and re-create the table.

You cannot truncate the parent table of an enabled referential integrity constraint. You must disable the constraint before truncating the table. (An exception is that you may truncate the table if the integrity constraint is self-referential.)

You cannot roll back a TRUNCATE statement.

Examples

Example I

The following statement deletes all rows from the EMP table and returns the freed space to the tablespace containing EMP:

TRUNCATE TABLE emp; 

The above statement also deletes all data from all indexes on EMP and returns the freed space to the tablespaces containing them.

Example II

The following statement deletes all rows from all tables in the CUST cluster, but leaves the freed space allocated to the tables:

TRUNCATE CLUSTER cust 
    REUSE STORAGE 

The above statement also deletes all data from all indexes on the tables in CUST.

Example III

The following statements are examples of truncate statements that preserve snapshot logs:

TRUNCATE TABLE emp PRESERVE SNAPSHOT LOG; 
TRUNCATE TABLE stock;

Related Topics

DELETE

DROP CLUSTER

DROP TABLE

UPDATE

Purpose

To change existing values in a table or in a view's base table.

You can use comments in an UPDATE statement to pass instructions, or hints, to the Oracle optimizer. The optimizer uses hints to choose an execution plan for the statement. For more information, see Oracle8 Tuning.

You can place a parallel hint immediately after the UPDATE keyword to parallelize both the underlying scan and UPDATE operations. For detailed information about parallel DML, see Oracle8 Tuning, Oracle8 Parallel Server Concepts & Administration, and Oracle8 Concepts.

Prerequisites

For you to update values in a table, the table must be in your own schema or you must have UPDATE privilege on the table.

For you to update values in the base table of a view,

• You must have UPDATE privilege on the view, and
• Whoever owns the schema containing the view must have UPDATE privilege on the base table.

If the SQL92_SECURITY initialization parameter is set to TRUE, then you must have SELECT privilege on the table whose column values you are referencing (such as the columns in a WHERE clause) to perform an UPDATE.

The UPDATE ANY TABLE system privilege also allows you to update values in any table or any view's base table.

Syntax

Keywords and Parameters

Updating Views

If a view was created with the WITH CHECK OPTION, you can update the view only if the resulting data satisfies the view's defining query.

You cannot update a view if the view's defining query contains one of the following constructs:

• set operator
• GROUP BY clause
• group function
• DISTINCT operator
• flattened subqueries
• nested table columns
• CAST and MULTISET expressions

Updating Partitioned Tables

When you create a partitioned table, you specify an ordered list of columns that determines into which partition a row or index entry belongs. These columns are the partitioning columns. The values in the partitioning columns of a row are the partitioning key for that row.

CREATE TABLE emp
  (emp_no NUMBER(5),
   dept VARCHAR2(2),
   name VARCHAR2 (30))
  STORAGE (INITIAL 100K NEXT 50K) LOGGING
  PARTITION BY RANGE (emp_no)
   ( PARTITION acct VALUES LESS THAN (1000)
     TABLESPACE ts1,
    PARTITION sales VALUES LESS THAN (2000)
     TABLESPACE ts2 
     PARTITION educ VALUES LESS THAN (3000) );

INSERT INTO EMP VALUES (1226, 'sa', 'smith');

INSERT INTO EMP VALUES (2100, 'ed', 'jones');

In the following example, employee SMITH is updated in the EMP table:

UPDATE emp SET emp_no = 1356
  WHERE name = 'SMITH';

The following statement is rejected because updating the row would cause JONES to move to another partition:

UPDATE emp SET emp_no = 1500 
  WHERE name = 'JONES';

Attempting to change the value of one or more columns that are part of the partitioning key would cause the updated row to migrate to another partition, thereby generating an error.

Updating a Single Partition

You do not need to specify the partition name when updating values in a partitioned table. However in some cases specifying the partition name can be more efficient than a complicated WHERE clause. To target a single partition of a partitioned table whose values you want to change, specify the PARTITION clause. This syntax can be less cumbersome than using a WHERE clause.

Example

The following example updates values in a single partition of the SALES table:

UPDATE sales PARTITION (feb96) s
   SET s.account_name = UPPER(s.account_name);

Correlated Update

If a subquery refers to columns from the updated table, Oracle evaluates the subquery once for each row, rather than once for the entire update. Such an update is called a correlated update. The reference to columns from the updated table is usually accomplished by means of a table alias.

Potentially, each row evaluated by an UPDATE statement could be updated with a different value as determined by the correlated subquery. Normal UPDATE statements update each row with the same value.

Example I

The following statement gives null commissions to all employees with the job TRAINEE:

UPDATE emp 
    SET comm = NULL 
    WHERE job = 'TRAINEE';

Example II

The following statement promotes JONES to manager of Department 20 with a $1,000 raise (assuming there is only one JONES):

UPDATE emp 
    SET job = 'MANAGER', sal = sal + 1000, deptno = 20 
    WHERE ename = 'JONES';

Example III

The following statement increases the balance of bank account number 5001 in the ACCOUNTS table on a remote database accessible through the database link BOSTON:

UPDATE accounts@boston 
    SET balance = balance + 500 
    WHERE acc_no = 5001;

Example IV

This example shows the following syntactic constructs of the UPDATE command:

• both forms of the SET clause together in a single statement
• a correlated subquery
• a WHERE clause to limit the updated rows

UPDATE emp a 
    SET deptno = 
        (SELECT deptno 
            FROM dept 
            WHERE loc = 'BOSTON'), 
        (sal, comm) = 
        (SELECT 1.1*AVG(sal), 1.5*AVG(comm) 
          FROM emp b 
          WHERE a.deptno = b.deptno) 
    WHERE deptno IN 
        (SELECT deptno 
          FROM dept 
          WHERE loc = 'DALLAS' 
              OR loc = 'DETROIT'); 

The above UPDATE statement performs the following operations:

• updates only those employees who work in Dallas or Detroit
• sets DEPTNO for these employees to the DEPTNO of Boston
• sets each employee's salary to 1.1 times the average salary of their department
• sets each employee's commission to 1.5 times the average commission of their department

Example V

The following example updates particular rows of the PROJS table:

UPDATE THE(SELECT projs 
           FROM dept d WHERE d.dno = 123)  p 
  SET p.budgets = p.budgets + 1 
  WHERE p.pno IN (123, 456);

The RETURNING Clause

You can use a RETURNING clause to return values from updated columns, and thereby eliminate the need to perform a SELECT following the UPDATE statement.

• When you are updating a single row, an UPDATE statement with a RETURNING clause can retrieve column expressions that use the updated columns of the row, ROWID, and REFs to the updated row and store them in PL/SQL variables or bind variables.
• When you are using an UPDATE statement with the RETURNING clause to update multiple rows, the values from expressions, ROWID, and REFs involving the updated rows are stored in bind arrays.

You can also use UPDATE with a RETURNING clause to update from views with single base tables.

Example

The following example returns values from the updated row and stores the result in PL/SQL variables BND1, BND2, BND3:

UPDATE emp
  SET job ='MANAGER', sal = sal + 1000, deptno = 20
  WHERE ename = 'JONES'
  RETURNING sal*0.25, ename, deptno INTO bnd1, bnd2, bnd3;

Related Topics

DELETE

INSERT

---

Prev   Next

Copyright © 1997 Oracle Corporation.  All Rights Reserved.

Library   Product   Contents   Index