Cursor Concurrency and Locking

When an application calls the SQLSetPos function to add, update, or delete a record, the Desktop Database Drivers can make sure that a record will stay in the same locked or unlocked state as it was in before SQLSetPos was called. To do this, SQLSetPos is called with an fLock argument of SQL_LOCK_NO_CHANGE. This uses the locking enforced by Microsoft Jet. To guarantee locking by Microsoft Jet, an application must create a keyset-driven cursor and specify SQL_CONCUR_LOCK for the SQL_CONCURRENCY fOption argument in SQLSetStmtOption.

Microsoft Jet does not support exclusive or explicit record-level locking. Therefore, the Desktop Database Drivers cannot lock the record specifically by using the SQL_LOCK_EXCLUSIVE fLock argument in SQLSetPos and then later unlock the record by using the SQL_LOCK_UNLOCK fLock argument. If a transaction is used (auto-commit mode off), setting the cursor-concurrency statement fOption argument to SQL_CONCUR_LOCK guarantees that the page-level locking supported by Microsoft Jet will be enforced for the duration of the transaction.

In addition to using Microsoft Jet locking (SQL_CONCURRENCY set to SQL_CONCUR_LOCK), you can also set the concurrency of a keyset-driven cursor to read-only (SQL_CONCUR_READ_ONLY), or optimistic concurrency in which record values are compared (SQL_CONCUR_VALUES). The Desktop Database Drivers do not support optimistic concurrency in which record versions are compared (SQL_CONCUR_ROWVER).

See Also For more information about page-level locking, see Chapter 10, “Managing Security.”