Updates the single row that is the current row of the cursor
After updating, the row remains the current row of the cursor
DELETE from table-name
WHERE CURRENT OF cursor-name
Deletes the single row that is the current row of the cursor
After deletion, the cursor has no current row. It is positioned in the “empty space” left by the deleted row, and will be advanced to the next row by a subsequent FETCH statement
There is no “positioned” insert statement
Strict criteria for positioned update and deletes
According to the SQL1 Standard, the query associated with the cursor
must draw its data from a single source table, not from a join.
cannot specify an ORDER BY clause.
cannot specify the DISTINCT keyword.
must not specify a GROUP BY or HAVING clause.
cannot use UNION or UNION ALL
cannot be a subquery in which the same table is specified in the FROM clauses of both the outer query and the subquery
The user must have the UPDATE or DELETE privilege on the base table.
In DB2, the cursor must be specified “FOR UPDATE OF column-name ” at the time it is declared
These rules can change with versions of DB2.
Declare Cursor statement with For Update clause
DECLARE CURSOR cursor-name FOR
FOR UPDATE OF column-name (, column-name…)
Declares the cursor will be updateable
Specifies which columns will be updated
Sometimes the database management system (DBMS) cannot determine whether a cursor is updateable or not. The cursor qualifies according to the criteria and the cursor select statement does not specify FOR UPDATE or FOR READ ONLY. This is called an ambiguous cursor .
DB2 does not permit updates within an ambiguous cursor. You get SQL bind error -510 “Table or view cannot be modified as requested” . DB2 does allow deletes within an ambiguous cursor, but the row is not locked before the delete.
Other Database Management Systems (DBMS) allow an ambiguous cursor and assume it may be updated. This causes extra work and extra locking.
Get in the habit of specifying FOR UPDATE or FOR READ ONLY. Programs that explicitly declare the intention to update are more easily maintained.
When the results table is materialized (we learned last week this may be at open time or fetch time), DB2 obtains a lock on a page as it is accessed.
Since our TSO compile option 5.7 specifies an isolation level of CURSOR STABILITY, read-only page locks are released as soon as a different page is accessed.
Page locks on data that is specified for update are not released until the updating program issues a Commit or Rollback.
Consequently, depending on the structure of the program, a lot of data can wind up being locked.
A batch program opening a large cursor may not issue a commit until it is finished. This won’t cause a problem if the program runs at night and no other processes are accessing the same data, but if other processes do access the data, they will have to wait.
An online program may open a small cursor with only a few rows. However, what if the user gets a phone call or goes to lunch before a commit is issued? Other users are meanwhile prevented from reading or updating data on those pages.
Cursor is originally opened for read-only, allowing locks to be released when the next page is accessed
Data is displayed to the user, who can scroll as desired
When the user makes a change and clicks SAVE, the updated row is selected again, this time for update
The timestamp column, LAST_UPDATE, is compared with the timestamp column of the row originally selected in the cursor.
If they match, we know the data has not been updated by someone else since our original select. The update is issued, followed by a commit.
If they don’t match, we know the data has been updated. A message is displayed to the user trying to do the update that the data has changed, and the new values are displayed. The user then can decide whether to proceed with the update.