Optimistic concurrency using batch mode updates. Status values returned for each row successfully updated.
Remarks
In order to maintain adequate control over the data being updated, RDO provides a number of concurrency options that control how other users are granted, or refused access to the data being updated. In many cases, when you lock a particular row using one of the LockType settings, the remote engine might also lock the entire page containing the row. If too many pages are locked, the remote engine might also escalate the page lock to a table lock to improve overall system performance.
Not all lock types are supported on all data sources. For example, for SQL Server and Oracle servers using the rdUseODBC cursor library, static-typerdoResultset objects can only support rdConcurValues or rdConcurReadOnly.
If the concurrency option is not supported by the data source, the driver substitutes a different concurrency option at execution time if one is available. If the driver cannot substitute a suitable alternative concurrency option, a trappable error is fired (SQLState Code 01S02 "Option Value Changed"). For rdConcurValues, the driver substitutes rdConcurRowVer and vice versa. For rdConcurLock, the driver substitutes, in order: rdConcurRowVer or rdConcurValues.
Choosing a Concurrency Option
Note RDO concurrency does not function as it does with Data Access Objects (DAO). Be sure to review the following sections to determine the best type of concurrency control for your application.
Read-Only Concurrency: This option does not impose any exclusive locks on the rows fetched. In most cases, however, you must be granted a share lock to gain access to the rows. In other words, other users cannot have exclusive locks (read-write or intend to write locks) on the pages being accessed. Choosing this option makes the cursor read-only. This does not preclude use of action queries to update the data independent of the cursor. This is the default LockType.
Pessimistic Concurrency: This option requests an immediate exclusive lock on the cursor rows which implements the lowest level of locking sufficient to ensure the row can be updated. Unlike DAO, which defers locking until the Edit method is used, RDO locks the first RowsetSize rows of the result set when the cursor is first opened with the OpenResultset method. That is, if your RowsetSize is 100 rows, the remote engine is instructed to lock each page that contains one of these selected rows. This means up to 100 pages can be locked – which can lock hundreds of rows. As the current row pointer is moved through the result set, additional pages are locked, and those no longer referenced are released. This technique assures your application that no other application is granted exclusive (read-write) access to any rows being processed by the cursor.
Optimistic Concurrency: This type of concurrency management does not lock any rows or pages – it simply compares the row being posted to the database with the row as it currently exists on the server. Depending on the type of optimistic concurrency chosen, RDO and the ODBC layers compare either the row ID, the row data values, TimeStamp columns or combinations of these options with existing data to determine if a row has changed since last fetched. If no changes have taken place since the last fetch, the update is made. Otherwise, your application triggers a trappable error.
The LockType property supports three types of optimistic concurrency as described below. When using the Optimistic Batch Concurrency option (rdConcurBatch), you should also set the UpdateCriteria property to choose an appropriate update concurrency option.
Optimistic Concurrency – Row Version: By comparing the row identifier (usually a TimeStamp column) , RDO can determine if the row has changed since last fetched. If it has, a trappable error results.
Optimistic Concurrency – Row Values: By comparing row values on a column-by-column basis, RDO can determine if the row has changed since last fetched. If it has, a trappable error results.
Optimistic Batch: This type of concurrency uses the UpdateCriteria property to determine how to test if rows have changed when using the UpdateBatch method.