Processing Positioned Update and Delete Statements

The cursor library supports positioned update and delete statements by replacing the WHERE CURRENT OF clause in such statements with a WHERE clause that enumerates the values stored in its cache for each bound column. The cursor library passes the newly constructed UPDATE and DELETE statements to the driver for execution. For positioned update statements, it then updates its cache from the values in the rowset buffers and sets the corresponding value in the row status array to SQL_ROW_UPDATED. For positioned delete statements, it sets the corresponding value in the row status array to SQL_ROW_DELETED.

Caution The WHERE clause constructed by the cursor library to identify the current row can fail to identify any rows, identify a different row, or identify more than one row. For more information, see “Constructing Searched Statements” later in this appendix.

Positioned update and delete statements are subject to the following restrictions:

Positioned update and delete statements can only be used when a SELECT statement generated the result set, the SELECT statement did not contain a join, a UNION clause, or a GROUP BY clause, and any columns that used an alias or expression in the select list were not bound with SQLBindCol.

If an application prepares a positioned update or delete statement, it must do so after it has called SQLFetch or SQLFetchScroll. Although the cursor library submits the statement to the driver for preparation, it closes the statement and executes it directly when the application calls SQLExecute.

If the driver only supports one active statement, the cursor library fetches the rest of the result set and then refetches the current rowset from its cache before it executes a positioned update or delete statement. If the application then calls a function that returns metadata in a result set (for example, SQLNumResultCols or SQLDescribeCol), the cursor library returns an error.

If a positioned update or delete statement is performed on a column of a table that includes a timestamp column that is automatically updated every time an update is performed, all subsequent positioned update or delete statements will fail if the timestamp column is bound. This occurs because the searched update or delete statement that the Cursor Library creates will not accurately identify the row to update. The value in the searched statement for the timestamp column will not match the automatically updated value of the timestamp column.