Normally, when a dynaset is created, rows are not locked in the database until StartEdit is invoked. If this is not desirable, the SQL SELECT statement could include the FOR UPDATE construct. Unfortunately, the FOR UPDATE construct
undermines the normal dynaset operations. You may use FOR UPDATE , but it is not
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 statements
will be treated as not FOR UPDATE - this means that rows are not locked during
the lifetime of the dynaset. If the FOR UPDATE is not recognized, rows will be
locked only during an StartEdit/Update sequence. However, during the StartEdit/Update sequence, the row is verified as unchanged before the StartEdit is permitted.
The use of FOR UPDATE on dynasets requires that a session transaction be in
progress at the time the dynaset is created. Further, before the session can be
committed or rolled back, the dynaset must be closed or an error is returned.
The dynaset is closed when all of the ODynaset objects that refer to it are
closed or are destroyed.
If an error results and the application terminates, uncommitted data is rolled
back, including pending FOR UPDATE dynasets.