The ADO Object Model
(Page 1 of 9 )
ADO, a data-access technology from Microsoft, offers a less strict data object model than its ancestors, DAO and RDO--which gives the programmer a great deal more flexibility and reduces development time. David Sussman gives a tour of the various objects and what to do with them. (
From ADO Programmer's Reference by David Sussman, published by Apress, ISBN 1590593421).
Like all other data-access technologies from Microsoft, ADO has a distinct object model that defines the objects and interfaces, and how the objects relate to each other. If you’ve done any database programming before, you are probably familiar with the general layout of these objects, because they lean heavily on the lessons learned from DAO and RDO. ADO has a good object model, but it is not as strict as its ancestors, so it gives the programmer a great deal more flexibility, thereby reducing development time. For example, in ADO you can create a recordset of data by using just a single line of code.
This has been achieved by flattening the object model. It’s still shown in the documentation as a hierarchy (with a single object at the top), but some of the lower objects can exist in your code in their own right, without the need to create higher-level objects explicitly. This means that a programmer can use the object most suitable for a particular task without having to create many other objects that aren’t really required in the program. If ADO requires these objects, it creates them and uses them behind the scenes—and you need never know that they are there.
The ADO Object Model Versions prior to 2.5 have three main objects: the Connection, the Command, and the Recordset. No hierarchy exists among the three main objects, and you can create them independently of each other. Versions 2.5 and higher make two new objects available: the Record and the Stream. This diagram shows the relationships among these objects in the ADO model:
The objects shown as shaded are collections. Each collection can comprise zero or more instances of its associated object, as shown in the following table:
| Collection | Associated Object |
|---|
| Errors | Error |
| Parameters | Parameter |
| Fields | Field |
| Properties | Property |
Note that although the main five objects all can exist independently in our code, the collections must be derived from their parent objects. So (for example) a Recordset contains a Fields collection, which in turn contains zero-or-more Field objects.
Enumerating the objects in a collection is the same for all collections; you just have to use a loop variable of the appropriate type. For example, in Visual Basic the following construct will step through each and every object in the Errors collection:
Dim objErr As ADODB.Error
For Each objErr In objConn.Errors
Debug.Print objErr.Description
Next
The same method can be used in VBScript, although you don’t give the object variable a specific type, because VBScript variables are Variants. For example, in ASP you could use:
Dim objFld
For Each objFld In objRec.Fields
Response.Write objFld.Name & "<BR>"
Next
In JScript you could use the Enumerator object. For example, in ASP you could use:
for(var objProp = new Enumerator(objConn.Properties);
!objProp.atEnd(); objProp.moveNext() )
{
Response.Write (objProp.item().Name + '<BR>');
}
 | This chapter is from ADO Programmer's Referencep,by David Sussman. (Apress, 2004, ISBN: 1590593421). Check it out at your favorite bookstore today. Buy this book now! |
Next: The Main ADO Objects >>
More ASP.NET Articles
More By Apress Publishing
/ 15 
