You use RESTORE to open a cursor saved with STORE.
The cursor is opened with the same cursor description as for the last OPEN. If host variables have been updated in the meantime, this does not have any effect on the resulting derived table.
If special literals or the time functions CURRENT_DATE, CURRENT_TIME and/or CURRENT_TIMESTAMP are included in the cursor description, they are not reevaluated.
A cursor position saved with STORE can be lost if, in the same or a different transaction, rows starting at the stored position have been deleted in the meantime, or the row on which the cursor was positioned has been updated in such a way that it no longer belongs to the cursor table.
If no cursor position has been saved for the cursor, the cursor is not opened and an appropriate SQLSTATE is set.
Otherwise, the cursor is opened and the cursor position restored. If you want to delete (DELETE ... WHERE CURRENT OF) or update (UPDATE ... WHERE CURRENT OF) a row, the cursor must be positioned on the row with FETCH.
After the RESTORE statement has been executed, all the information on this cursor that has been saved with STORE is deleted. You must save the cursor position again with store before a new RESTORE statement can be executed.
The cursor to be restored must be saved with STORE and must be closed when RESTORE is executed. The transactions containing the STORE and RESTORE statements must have the same isolation level.
For a dynamic cursor, the cursor description must be still be prepared when the RESTORE statement is executed (see also "Validity period of a prepared statement").
RESTORE must not be used for cursors defined with WITH HOLD.
RESTORE cursor
cursor
Name of the cursor to be restored.
Processing the cursor after RESTORE
After a RESTORE statement, you must position the cursor on a row with FETCH.
Example
FETCH NEXT positions to the next row in the cursor table.
Only then can the cursor be accessed with an UPDATE or DELETE statement.
See also
DECLARE CURSOR, OPEN, STORE, FETCH, UPDATE, DELETE