ADO is made up of three primary objects: Connection, Command, and Recordset. The Connection object is used to open a channel between the program and a data source. Connection allows you to set the connection string as well as handle transactions and set the type of cursor. ADO supports server-side and client-side servers as well as many other cursor properties designed to control the visibility of modified records and so on. The Command object is used to execute queries. These queries can be arbitrary SQL strings, or possibly stored procedures. The Command object supports parameters, and this support helps with passing values that might be troublesome if they were passed as part of an arbitrary SQL string. For example, consider the following SQL string:
SELECT * FROM Titles WHERE Title='What's Up Doc?'
This string will fail because the apostrophe in the title will be seen as the end of the string, and the rest of the title will be rejected as invalid syntax. Using parameters on the Command object allows such a string to be handled.
The Recordset object is used to get data from the data source and to navigate through the recordset. Depending on the type of cursor, the recordset can be navigated both forward and backward and can provide properties such as the record count.
One core weakness of ADO is the level of complexity that's involved with selecting the correct cursor location, cursor type, and other similar details. For example, how do you know whether to use a client-side or a server-side cursor? What type of locking do you want? Should other users see changes you make to the recordset before you commit the changes? Although ADO offers flexibility, for the majority of users, especially ASP users, ADO is tough to master and use correctly.
Was this article helpful?