Chapter 2 -- A Brief Overview of the ADO Object Model

[Previous] [Next]

Chapter 2

Those of you familiar with the Data Access Objects (DAO) and Remote Data Objects (RDO) object models might find the ADO object model somewhat of a departure. For example, ADO allows you to retrieve data from a database into a Recordset object without having to create a Connection object or any other object variables. You can create most of ADO's objects on their own without calling a function on another object to generate them.

ADO's creatable objects provide developers with a great deal of flexibility in how they build their applications; nevertheless, creatable objects can present a challenge to someone learning to use ADO. A developer who provides code in a magazine or Web site article to illustrate how he used ADO in his application doesn't usually explain why he chose to implement his solution that way. As a result, the reader of that article only picks up a small piece of the puzzle.

This chapter will briefly cover the three main ADO objects—Connection, Command, and Recordset—treating them initially as a hierarchy to show how they relate to each other. (See Figure 2-1.) Then we'll talk about how to avoid using the object hierarchy, and when it's appropriate to do so. (In subsequent chapters, we'll take a closer look at each of these objects and discuss ADO's use of dynamic properties.) After that, we'll explain the different ways you can create a disconnected recordset—one that is not connected to any database. Finally, we'll discuss ADO 2.5's additions to the object model: the Record object and the Stream object.

Figure 2-1 The ADO object model.