Data Access and Transactions
Data Access and Transactions |
|
In order to use a client-side cursor, you must change the CursorLocation property before you open a Recordset, as in the following:
rs.CursorLocation = adUseClient
The client-side cursor engine creates a disconnected RDS Recordset, such as you would find on the client tier. Of course, this also requires the database to return all the records that satisfy the query when the Recordset is opened. For this reason, no matter what value you select for CursorType, you will really only have a static snapshot of the data when using client-side cursors.
Note Because updates to a disconnected Recordset aren’t immediately communicated to the server, you won’t be notified of Recordset concurrency errors immediately, as you are with server-side cursors.
Two additional CursorLocation values are available: adUseClientBatch (for use with adLockBatchOptimistic concurrency setting) and adUseNone. The adUseNone value instructs ADO to forgo its normal rowset helper support, which provides extra cursor functionality beyond that which the OLE DB provider may support. When you specify adUseNone, you are effectively telling ADO not to include this additional service provider.
Client-side cursors can be used to extend the functionality of the existing driver-supplied OLE DB cursor support. It is possible that the client-side cursor engine can support functionality that is unavailable from the DBMS driver itself, as is the case with the Oracle driver. The RDS client-side cursor may also support features that your server-side cursors do not. For example, you can only use absolute page positioning against a data source by using a client-side cursor.