The ODBCDirect cursor library provides the four cursor types listed in the following table.
Cursor type | Constant |
Dynamic cursor | dbOpenDynamic |
Keyset cursor | dbOpenDynaset |
Static cursor | dbOpenSnapshot |
Forward-only scrolling cursor | dbOpenForwardOnly |
You can control how the data source and the ODBCDirect cursor library manage concurrency with the locking options listed in the following table.
Locking type | Constant |
Pessimistic concurrency. | dbPessimistic |
Optimistic concurrency using row versions. | dbOptimistic |
Optimistic concurrency using row values. | dbOptimisticValue |
Optimistic batch updating means that the data for a given result set is cached locally. All changes to the result set are also cached locally. If the batch update tries (optimistically) to change a record that has been changed by another source, your application can find out which rows failed in order to determine how to reconcile the failed updates. Batch updating is fast because it cuts down on network traffic between the client and server. This type of lock is a good choice if your application does not need to issue update requests one row at a time. | dbOptimisticBatch |
Read-only. Changes are not permitted. | dbReadOnly |
ODBCDirect cursors have limitations, as described below.
If your application must read or set the field value for one of these data types more than once, you should refresh the current row immediately after reading or setting the value property. The simplest way to refresh the current row is to ask the cursor to Move 0
.
For More Information For more information on the ODBCDirect cursor library, search online for "Using Cursors in ODBCDirect Workspaces" in MSDN Library Visual Studio 6.0. For more information on using locks to handle multiuser concurrency situations, see Managing Concurrency with Cursor Locks.