A cursor in a database context represents a facility for managing recordsets
as discrete rows of data. A cursor enables you to move through a set of records and implements
a pointer to a current row in the set of records.
You don't have to use a cursor to access data from an ADO provider.
Instead, you can manipulate the data through straight SQL statements or stored procedures—and
you should do so when possible, because a cursor represents a certain amount of resource overhead.
Nevertheless, cursors are often necessary to efficient data processing. Anytime
that you create a Recordset in ADO, you create a cursor to go along with it.
You have several choices to make when you use a cursor:
-
Cursor location. You can determine whether a cursor is implemented
by the local workstation, or whether it is implemented by the server.
-
Cursor behavior. You can determine how freely a cursor can move
at the request of the consumer and how dynamically it reflects concurrent changes to data made
by other users.
The following sections discuss these two issues as well as how to implement
various locking strategies with cursors.
NOTE - Cursor Behavior Not Always as Advertised: Because
of the great array of DBMSs that lie behind cursorimplemented rowsets, you may
find that some cursor types will give you more or less functionality than documented
for a particular combination of cursor location, cursor type, or locking strategy.
