To support data integrity and avoid conflicts between users trying to update
the same data at the same time (concurrency conflicts), most modern DBMSs support some sort
of locking scheme.
ADO recognizes four different types of data locking, represented by four enumerated
constants:
-
adLockReadOnly (default)
- When a recordset is opened, the user may not make any changes to the data. This ensures
that concurrency conflicts with other users are avoided.
-
adLockPessimistic - Provider guarantees that a record under
editing will be able to have its changes saved. This is usually accomplished by locking
the record as soon as it becomes the current record under a cursor. The lock is released
when the cursor moves off the record or the recordset is closed.
-
adLockOptimistic - Provider does not guarantee that a record under editing
will have its changes saved. Provider locks the record only during the update process.
-
adLockBatchOptimistic - For server-side cursors, this option guarantees
that all cursor options will be supported in the most efficient way.
You can set the type of lock on the data underlying a Recordset by setting
the Recordset's LockType property to one of the previously mentioned values before you
open it.
NOTE - The Most Economical Cursor: As stated
earlier in this chapter, the most efficient cursor in terms of resource usage
is a Forward-Only cursor with its lock type set to Read-Only. This type of cursor
is also known as a "firehose cursor." See the subsection titled "Forward-Only
Cursor" under the section "Using Cursor Types" for more information on the Forward-
Only cursor type
