ADO Tips and Best Practices Object Declaration/Initialization: 1. Always use separate statements for declaration and initialization.

(This increases performance and provides more control) Connection Object: 1. Never assume your connection will open. (There's always a charce for errors) 2. Use identical connection string to connect to a single data source from multiple Connection object. (This uses connection pool to utilize discarded connections) 3. Use in-connection strings rather than DNS or UDL. 4. Don't use cursors. Use client-side cursor if possible and necessary. 5. Try opening connection asynchronously and determine the connection result by checking Status argument of ConnectionComplete event (set to adStatusOK when connected) or checking Connection object's State against adStateConnecting and adStateOpen 6. To poll or ping the connection try sending a low-impact query, such as SELECT 1. 7. Be sure to handle following most common errors: i. Error.Number-2147467259 (080004005) is fired for connection-related issues, anything that prevents ADO from connecting to server ii. Error.Number-2147217843 (080040E4D) is fired for logon issues iii. Error.Number-2147221020 (0800404) is fired when the syntax of the ConnectionString is incorrect Command Object: 1. Consider using Command object for all (adhoc/sp/vu/table etc) query execution. Construct separate Command objects for all quries at startup and reuse them by changing parameters. 2. Assign name property of command object meaningfully to add that name to connection object as a method. 3. Don't set Prepared property to True for the command object 4. There are 4 phases to the creation and execution of Command objects: i. Create the Command object and construct the Parameters collection. ii. Set the Parameter Value property for each input parameter. iii. Execute the query. iv. Process the results Phase i should be executed once. Remaining phases can be done as and when required.

5. Take following steps to accomplish Phase i (above) for a command object:

i. Declare the Command object(s) ii. Name the Command object(s) iii. Set the CommandText property iv. Set the CommandType property v. Set the ActiveConnection property vi. Construct the Parameters collection (by calling Refresh method or appending by code) 6. Consider using Refresh method for constructing Parameters collection 7. A command object can be executed in several ways: i. Using the Execute method on the constructed Command object (returns ReadOnly/ForwardOnly faster recordset; params can be passed as a variant array or set individually; returns number of rows affected; try using CommandType flags; ExecuteComplete event fires at the end; returns output params) ii. Using the Command object as a method on the Connection object (takes a pre-constructed Recordset object for results; excellent performance) iii. Referencing the Command with the Execute method on the Connection object ( iv. Referencing the Command with the Open method on the Recordset object

8. Intelligent Query Authoring Techniques: v. Fetch just the columns you need, and no more (SELECT * is bad unless required)
vi.

vii. viii. ix.

Fetch just the rows you need and no more Incorporate cursors in your application only when absolutelsy necessary Consider using Return Status, OUTPUT, or INPUT-OUTPUT parameters instead of Recordsets to retrieve data values. If you simply must create a cursor, build a scrollable cursor only when absolutely necessary

x. If you choose pessimistic locking, be careful about the size of the fetched rowset xi. When you initially fetch rows from the server, don't let the user govern when (or if) the rowset is completely fetched (avoid running queries on First, Prv, Next, Last) xii. Don't run a hard-coded query when you can run a stored procedure. xiii. When running ad-hoc queries, don't set the Prepared property to True. xiv. Consider what your application does to the server and other users - not just client. xv. Monitor the impact your application has on the server, Use the SQL Profiler 9. Try to Preset Execution Options. You have to pass these options to the Execute method 10. CommandTimeout Property to a realistic value 11. Create an enumeration for parameters instead of string reference 12. When running queries with command object, the quotes are automatically framed by ADO 13. Errors a. -2147217900 when some required parameter value is missing (Msg: Incorrect syntax near the keyword 'DEFAULT') Recordset Object: 1. When running queries, consider if it is extremely necessary to use a Recordset object. Many queries can return the required information as output parameters or status values 2. Execute method manufactures a brand new Recordset on its own, using the default Recordset configuration 3. ADO's default recordset (that is returned by Execute methods of Command and Connection object) is Read-only/Forward-only (i. e. cursorless), and therefore a better choice if returned data is not meant for updating or scrolling back and forth. 4. Each option that varies from default ADO recordset costs time and resources to implement. 5. Execute method is preferable if no result set is expected or needed in return. 6. It should be considered that Open method of Recordset object constructs a Command object behind the scenes to execute the Source, so no efficiency is gained by avoiding explicit Command object 7. Options argument is important to be set properly for Open method 8.