| Microsoft Office 2000/Visual Basic Programmer's Guide | |
Although ADO objects can be created outside the scope of a hierarchy, the objects exist within hierarchical relationships, as shown in the Microsoft ActiveX Data Objects 2.1 Object Model in the Object Model Guide.
The four primary ADO objects — the Connection, Command, Recordset, and Field objects — each has a Properties collection that is used to expose dynamic properties or provider-specific properties on these objects. Properties in these collections are required for provider-specific settings that aren't available through standard ADO properties and methods. For more information about provider-specific properties, see "Provider-Specific Properties Collections" later in this chapter.
The following sections provide a brief overview of these objects; each one is discussed in greater detail later in this chapter or in other chapters.
The Connection object is the top-level object in the ADO hierarchy. It represents the connection made to the data source through the OLE DB data provider, and handles all communication between your solution and a data source. Unlike the Connection object in DAO's ODBCDirect or in Remote Data Objects (RDO), you don't have to instantiate an ADO Connection object before you create other objects such as the Command or Recordset object. This lets you create temporary objects and associate them with a Connection object as needed.
You open and close a Connection object by using the Open and Close methods. Additionally, Connection objects provide transaction support by using the BeginTrans, CommitTrans, and RollbackTrans methods. Use transactions when you want to save or cancel a series of changes made to the source data as a single unit. For example, if you are transferring money between two accounts, you want to make sure that both debiting and crediting operations occur. By making these changes within a transaction, you ensure that either all or none of the changes go through. This chapter discusses opening and working with Connection objects; however, working with transactions is discussed in Chapter 16, "Multiuser Database Solutions."
The Command object represents an SQL statement, stored procedure, or any other command that can be processed by the data source. The Command object is similar to a DAO temporary QueryDef object, including a Parameters collection that can accept input and output parameters. You can execute a command string on a Connection object (by using the Execute method) or pass a query string as part of opening a Recordset object (as the Source property), without explicitly creating a Command object. The Command object is most useful when you want to define query parameters, or execute a stored procedure that returns output parameters. You can also use a Command object in conjunction with the ADO Views and Procedures collections to store queries in your database. For information about using the Command object to work with stored queries, see "Creating and Modifying Stored Queries" later in this chapter. For information about using the Command object to open a parameter query, see "Opening a Query That Has Parameters" later in this chapter.
The Recordset object represents a set of records returned from a query, and a cursor into those records. You can open a Recordset object without explicitly opening a Connection object by passing a connection string to the Recordset object's Open method. However, if you create and open a Connection object, you can open multiple Recordset objects on the same connection. The Recordset object contains a Fields collection that contains Field objects, each of which represents a single column of data within a Recordset object. For information about using the Recordset object, see "Working with Records" later in this chapter.
The Error object contains extended error information about an error condition raised by the OLE DB provider. Because a single statement can generate one or more errors, the Errors collection can contain more than one Error object at a time, and all of them can result from the same incident. For information about using the ADO Error object, see "The ADO Error Object and Errors Collection" in Chapter 8, "Error Handling and Debugging."
Note Jet database engine error numbers aren't returned by the Number property of either the VBA Err object or the ADO Error object. To retrieve Jet error numbers from ADO, you must use the SQLState property of the ADO Error object instead.