The CursorDriver property only affects connections established after the CursorDriver property has been set — the property is read-only on existing connections.
When the initial (default), and each subsequent rdoEnvironment object is created, the CursorDriver property is set from the rdoEngine object's rdoDefaultCursorDriver property which is set using the same constants.
Choosing a Cursor Driver
Choosing the right cursor driver can have a significant impact on the overall performance of your application, what resources are consumed by the cursor, and limit the type or complexity of the cursors you create. Each type of cursor has its own benefits and limitations. In many cases, the best choice is no cursor at all because your application often does not need to scroll through the data or perform update operations against a keyset.
The following paragraphs outline the functionality and suggested purposes for each of the cursor types.
Server-Side Cursors
This cursor library maintains the cursor keyset on the server (in TempDB) which eliminates the need to transmit the keyset to the workstation where it consumes needed resources. However, this cursor driver consumes TempDB space on the remote server so this database must be expanded to meet this requirement. Cursors created with the server-side driver cannot contain more than one SELECT statement – if they do, a trappable error is fired. You can still use the server-side cursor driver with multiple result set queries if you disable the cursor by creating a forward-only, read-only cursor with a rowset size of one. Not all remote servers support server-side cursors. Note that server-side cursors are enabled when using either rdUseIfNeeded or rdUseServer against Microsoft SQL Server databases.
ODBC Client-Side Cursors
This cursor library builds keysets on the workstation in local RAM overflowing to disk if necessary. Because of this design considerably more network operations must be performed to initially create the keyset, but with small cursors this should not impose a significant load on the workstation or network. ODBC client-side cursors do not impose any type of restriction on the type of query executed. This option gives better performance for small result sets, but degrades quickly for larger result sets.
Client-Batch Cursors
This cursor library is designed to deal with the special requirements of optimistic batch updates and several other more complex cursor features. Client-batch cursors are required for dissociate connections, batch mode, and multi-table updates. This cursor also supports delayed BLOB column fetch, buffered cursors, and additional control over updates. This library is somewhat larger than the others, but also performs better in many situations.
The No-Cursor Option
In cases where you need to fetch rows quickly, or perform action queries against the database without the overhead of a cursor, you can choose to instruct RDO to bypass creation of a cursor. Basically, this option creates a forward-only, read-only result set with a RowsetSize set to 1. This option can improve performance in many operations. While you cannot update rows or scroll between rows with this cursor, you can submit independent action queries to manipulate data. This option is especially useful when accessing data through stored procedures.