Normally, when a dynaset is created, rows are not locked in the database until
Edit is invoked. If this is not desirable, you might include the FOR UPDATE
construct in the SQL SELECT statement. Unfortunately, the FOR UPDATE construct
undermines normal dynaset operations, so Oracle does not recommend its use.
Dynasets created with FOR UPDATE are handled correctly in most cases by
scanning the SQL statement for the FOR UPDATE construct (This is necessary because
the Oracle database functions do not distinguish between SELECT and SELECT FOR
UPDATE SQL statements.) It is possible that some exotic FOR UPDATE SQL statement
will be treated as "not FOR UPDATE"—meaning that rows are not locked during the lifetime of the dynaset. If the
FOR UPDATE is not recognized, rows are locked only during an Edit/Update
sequence. However, during the Edit/Update sequence, the row is verified as unchanged
before the Edit is permitted.
The use of FOR UPDATE on dynasets requires that a session level transaction be
in progress at the time the dynaset is created. Further, before the session
can be committed or rolled back, all objects which reference the dynaset must be
set to "Nothing" or an error is returned. In the case of a data control, change
the record source and Refresh the data control or Recordset.
Note that if an error results and the application terminates, uncommitted data
is rolled back, including pending FOR UPDATE dynasets.