The UPDATE statement updates the values of specified columns in rows of a table or view. Updating a row of a view updates a row of its base table, if no INSTEAD OF UPDATE trigger is defined on this view. If such a trigger is defined, the trigger will be executed instead.
There are two forms of this statement:
A Searched UPDATE statement can be embedded in an application program or issued interactively. A Positioned UPDATE must be embedded in an application program. Both forms are executable statements that can be dynamically prepared.
The privileges held by the authorization ID of the statement must include at least one of the following:
If the expression in the assignment-clause contains a reference to a column of the table or view, or if the search-condition in a Searched UPDATE contains a reference to a column of the table or view, then the privileges held by the authorization ID of the statement must also include one of the following:
If the search-condition includes a subquery or if the assignment-clause includes a scalar-fullselect or row-fullselect, see Queries for an explanation of the authorization required for each subselect.
For information on the system authorities corresponding to SQL privileges, see Corresponding System Authorities When Checking Privileges to a Table or View.
Searched UPDATE:
Positioned UPDATE:
If neither OVERRIDING SYSTEM VALUE or OVERRIDING USER VALUE is specified:
If a value is not specified the database manager generates a new value.
For a Positioned UPDATE:
For more information, see update-clause.
A view column derived from the same column as another column of the view can be updated, but both columns cannot be updated in the same UPDATE statement.
If a list of column-names is specified, the number of expressions, NULLs, and DEFAULTS must match the number of column-names.
The number of expressions, NULLs, and DEFAULTs (or the number of result columns from a row-fullselect) must match the number of columns in the row.
For a Positioned UPDATE, if the UPDATE clause was specified in the SELECT statement of the cursor, each column of the table or view must also appear in the UPDATE clause. For more information, see update-clause.
ROW may not be specified for a view that contains a view column derived from the same column as another column of the view, because both columns cannot be updated in the same UPDATE statement.
A column-name in an expression must name a column of the named table or view. For each row updated, the value of the column in the expression is the value of the column in the row before the row is updated.
Each variable in the clause must identify a host structure or variable that is declared in accordance with the rules for declaring host structures and variables. In the operational form of the statement, a reference to a host structure is replaced by a reference to each of its variables. For further information on variables and structures, see References to host variables and Host structures. If a host structure is specified, the keyword ROW must be specified.
The row-fullselect may contain references to columns of the target table of the UPDATE statement. For each row updated, the value of such a column in the expression is the value of the column in the row before the row is updated.
The search-condition is applied to each row of the table or view. The updated rows are those for which the results of the search-condition are true.
If the search-condition contains a subquery, the subquery can be thought of as being executed each time the search-condition is applied to a row, and the results of that subquery used in applying the search-condition. In actuality, a subquery with no correlated references may be executed only once. A subquery with a correlated reference may have to be executed once for each row.
The table or view named must also be named in the FROM clause of the SELECT statement of the cursor, and the result table of the cursor must not be read-only. For an explanation of read-only result tables, see DECLARE CURSOR.
When the UPDATE statement is executed, the cursor must be positioned on a row; that row is updated.
Introduces the isolation level, which may be one of:
Assignment: Update values are assigned to columns in accordance with the storage assignment rules described in Assignments and comparisons.
Validity: Updates must obey the following rules. If they do not, or if any other errors occur during the execution of the UPDATE statement, no rows are updated.
All uniqueness checks are effectively made at the end of the statement. In the case of a multiple-row UPDATE of a column involved in a unique index or unique constraint, this would occur after all rows were updated.
All check constraints are effectively validated at the end of the statement. In the case of a multiple-row UPDATE, this would occur after all rows were updated.
Triggers: If the identified table or the base table of the identified view has an update trigger, the trigger is activated. A trigger might cause other statements to be executed or raise error conditions based on the updated values.
Referential Integrity: The value of the parent key in a parent row must not be changed.
If the update values produce a foreign key that is nonnull, the foreign key must be equal to some value of the parent key of the parent table of the relationship.
The referential constraints (other than a referential constraint with a RESTRICT delete rule) are effectively checked at the end of the statement. In the case of a multiple-row UPDATE, this would occur after all rows were updated.
Update operation errors: If an update value violates any constraints, or if any other error occurs during the execution of the UPDATE statement and COMMIT(*NONE) was not specified, all changes made during the execution of the statement are backed out. However, other changes in the unit of work made prior to the error are not backed out. If COMMIT(*NONE) is specified, changes are not backed out.
It is possible for an error to occur that makes the state of the cursor unpredictable.
Number of rows updated: When an UPDATE statement completes execution, the number of rows updated is returned in the ROW_COUNT statement information item in the SQL Diagnostics Area (and SQLERRD(3) in the SQLCA). For a description of the SQLCA, see Appendix C. SQLCA (SQL communication area).
Locking: Unless appropriate locks already exist, one or more exclusive locks are acquired by the execution of a successful UPDATE statement. Until these locks are released by a commit or rollback operation, the updated rows can only be accessed by:
The locks can prevent other application processes from performing operations on the table. For further information about locking, see the description of the COMMIT, ROLLBACK, and LOCK TABLE statements, and isolation levels in Isolation level. Also, see the Database Programming book.
A maximum of 500 000 000 rows can be updated or changed in any single UPDATE statement when COMMIT(*RR), COMMIT(*ALL), COMMIT(*CS), or COMMIT(*CHG) has been specified. The number of rows changed includes any rows inserted, updated, or deleted under the same commitment definition as a result of a trigger.
REXX: Variables cannot be used in the UPDATE statement within a REXX procedure. Instead, the UPDATE must be the object of a PREPARE and EXECUTE using parameter markers.
Datalinks: If the URL value of a DATALINK column is updated, this is the same as deleting the old DATALINK value then inserting the new one. First, if the old value was linked to a file, that file is unlinked. Then, unless the linkage attributes of the DATALINK value are empty, the specified file is linked to that column.
The comment value of a DATALINK column can be updated without relinking the file by specifying an empty string as the URL path (for example, as the data-location argument of the DLVALUE scalar function or by specifying the new value to be the same as the old value). If a DATALINK column is updated with a null, it is the same as deleting the existing DATALINK value.
An error may occur when attempting to update a DATALINK value if the file server of either the existing value or the new value is no longer registered with the database server
Syntax alternatives: The following keywords are synonyms supported for compatibility to prior releases. These keywords are non-standard and should not be used:
Example 1: Change the job (JOB) of employee number (EMPNO) '000290' in the EMPLOYEE table to 'LABORER'.
UPDATE EMPLOYEE SET JOB = 'LABORER' WHERE EMPNO = '000290'
Example 2: Increase the project staffing (PRSTAFF) by 1.5 for all projects that department (DEPTNO) 'D21' is responsible for in the PROJECT table.
UPDATE PROJECT SET PRSTAFF = PRSTAFF + 1.5 WHERE DEPTNO = 'D21'
Example 3: All the employees except the manager of department (WORKDEPT) 'E21' have been temporarily reassigned. Indicate this by changing their job (JOB) to NULL and their pay (SALARY, BONUS, COMM) values to zero in the EMPLOYEE table.
UPDATE EMPLOYEE SET JOB=NULL, SALARY=0, BONUS=0, COMM=0 WHERE WORKDEPT = 'E21' AND JOB <> 'MANAGER'
Example 4: In a Java™ program display the rows from the EMPLOYEE table on the connection context 'ctx' and then, if requested to do so, change the job (JOB) of certain employees to the new job keyed in (NEWJOB).
#sql iterator empIterator implements sqlj.runtime.ForUpdate
with( updateColumns='JOB' )
( ... );
empIterator C1;
#sql [ctx] C1 = { SELECT * FROM EMPLOYEE };
#sql { FETCH :C1 INTO ... };
while ( !C1.endFetch() ) {
System.out.println( ... );
...
if ( condition for updating row ) {
#sql [ctx] { UPDATE EMPLOYEE
SET JOB = :NEWJOB
WHERE CURRENT OF :C1 };
}
#sql { FETCH :C1 INTO ... };
}
C1.close();