Choose Your Cursor Location, Cursor Type, and Lock Type with Care

Choose your cursor location, cursor type, and lock type with care If you don’t need scrolling or updatability, don’t ask for it. The ADO defaults of adUseServer, adOpenForwardOnly, and adLockReadOnly offer you the best performance for doing a forward-only scan through the records. Don’t ask for a more functional cursor if your application doesn’t require it. If you do want scrolling, don’t default to server cursors as ADO does. The ADO CursorLocation default is adUseServer primarily for backward compatibility reasons. However, for most scrolling scenarios, you will be much better off with a client cursor. Only in specific scenarios, such as extremely large data sets, will you be better off with a server cursor. When using a client cursor, don’t ask for anything other than adLockReadOnly LockType unless you really need it. If you ask for updatability, the client cursor engine needs to get additional metadata, which can be very expensive to retrieve.

Tune your Recordset CacheSize property ADO uses the Recordset CacheSize property to determine the number of rows to fetch and cache. While you are within the range of cached rows, ADO just returns data from the cache. When you scroll out of the range of cached rows, ADO releases the cache and fetches the next CacheSize rows. So what CacheSize should you use in your application? Unfortunately, there isn’t a single optimal CacheSize that is appropriate for all applications. You should tune your application with different CacheSize values and use the one that offers you the best performance. Using a small CacheSize value significantly improves performance for fetching data from an Oracle data store.

Describe command parameters yourself In many data stores, getting command parameter information is often as expensive as executing the command. So when possible, describe the command parameters yourself, as in UserDescribedParameters, instead of getting the parameter information from the provider, as the code in ProviderDescribedParameters does. Sub UserDescribedParameters()

Dim cmd As New Command

cmd.ActiveConnection = "Provider=SQLOLEDB;Data Source=server;Database=pubs;User Id=sa;Password=;"

cmd.CommandText = "CreditAccount" cmd.CommandType = adCmdStoredProc cmd.Parameters.Append cmd.CreateParameter("Return Value", adInteger, adParamReturnValue) cmd.Parameters.Append cmd.CreateParameter("Credit", adInteger, adParamInput) cmd.Parameters.Append cmd.CreateParameter("Balance", adInteger, adParamOutput)

cmd.Parameters(1).Value = 100 cmd.Execute Debug.Print cmd.Parameters(0).Value, cmd.Parameters(2).Value

End Sub

Sub ProviderDescribedParameters()

Dim cmd As New Command

cmd.ActiveConnection = "Provider=SQLOLEDB;Data Source=server;Database=pubs;User Id=sa;Password=;"

cmd.CommandText = "CreditAccount" cmd.CommandType = adCmdStoredProc cmd.Parameters.Refresh

cmd.Parameters(1).Value = 100 cmd.Execute Debug.Print cmd.Parameters(0).Value, cmd.Parameters(2).Value

End Sub

Use native OLE DB providers MDAC 2.0 ships with native providers for three SQL data stores—SQL Server, Oracle, and Jet (.mdb). With earlier versions, you had to go through the OLE DB Provider for ODBC Data, which in turn used the appropriate ODBC driver to access these data stores. With MDAC 2.0, you can use these native OLE DB providers to access your data faster and with lower disk and memory footprint. The SQL Server provider is written to TDS, the Oracle provider to OCI, and the Jet provider to Microsoft Jet engine interfaces.

Use Connection::Execute for single execution ADO 2.0 has some optimizations for one-time command executions when done through Connection::Execute. This is a common user scenario in Internet Information Server (IIS), Active Server Pages (ASP), and Microsoft Transaction Server environments, where the code typically opens a connection, executes a row or non-row returning command, processes results, and closes the connection. For such scenarios, use Connection::Execute instead of Recordset::Open or Command::Execute. When you use Connection::Execute, ADO doesn’t preserve any command state information and therefore leads to an improvement in performance. Note that you may still need to use Recordset::Open or Command::Execute if you need a more functional cursor or if you need to use Command::Parameters. Use ADO like an Apartment model Though the ADO implementation is free-threaded, don’t use it in that way in the middle tier. Don’t cache an instance of an ADO object, say Connection, globally and invoke methods on it concurrently from multiple threads. If each client request in your application model invokes the Connection::Execute method on a globally cached Connection object on the middle tier, your application will not scale. This is because of synchronization in the Connection::Execute method. You will get much better throughput by using an application model where each client request creates a new instance of a Connection object, calls Connection::Open, Connection::Execute, and releases the Connection object on the middle tier. Each request does have the additional overhead of creating a new instance of a Connection object and obtaining a connection from the connection pool. However, because your Connection::Execute call isn’t synchronized, the throughput is much better.

Use ADO marked as Apartment model when using it like an Apartment model ADO 2.0 includes some optimizations when marked as an Apartment model. It determines the threading model from the registry at DLL load time. If the threading model is Apartment, only the class factories and globals are protected with critical sections. At all other places in code, ADO doesn’t initialize, delete, enter, or leave critical sections. This leads to a significant improvement in the scaling characteristic of ADO applications. The default threading model of ADO 2.0 is Apartment, as in ADO 1.0 and 1.5, so you don’t have to do anything to take advantage of this optimization other than use ADO like an Apartment model.