The ADO Object Model - Revisited
Remember when we looked at the DAO object model back in Chapter 9? Well, you will be pleased to know that the ADO model is much flatter. There are fewer collections, but the model sports much more functionality.
Here is a slightly different slant on the ADO object model than we presented at the beginning of the chapter. It has the same information, but here it is presented a bit differently. The gray boxes represent collections. Remember when we iterated through each of the errors in the Errors Collection?
.gif)
There are some differences between the DAO and ADO object model. For example, all objects represented can be created independently. The exceptions are the Error and Field objects because they are dependent on the Connection and Recordset objects respectively. Otherwise, they make no sense!
Notice that the DAO hierarchy that all database programmers are used to has deliberately been de-emphasized in the ADO model. This will give you much more flexibility to reuse objects across various context boundaries. What does this mean exactly? Well, in ADO you can create a singleCommand object. Then you can use it with more than one Connection object.
Recall that the Connection object represents a connection to the underlying data source. In our previous examples, we illustrated the connection object talking to our Access Biblio.mdb data source. The Connection interface provides an Execute method. We used this to process a SQL command via the connection.
We also mentioned that if the command generates rows, a default Recordset object will be returned. However, if you need to use a more specialized or complex Recordset object with data returned from the Connection, you should create the new Recordset object (specifying the way you need it to behave), bind it to the Connection, and open the cursor (more about cursors in a moment).