LOOKING AT THE OBJECT MODELS

That's right, object models, plural. Unlike DAO, which consists of one object model (see Figure 6.1), ADO has three separate object models.

ADO's object models work together to give you the objects and collections necessary to work with your data. The three object models consist of

• ActiveX Data Objects 2.1 (ADODB) let you create and work with recordsets, as well as perform error handling.

• ADO Extensions 2.1 for DDL and Security (ADOX) is the data definition language, allowing you to work with and modify the database schema. Security objects are also included in this object model.

• Jet and Replication Objects 2.1 (JRO) enable you to work with the Jet engine and replication.

Although these are separate object models and will be explained as such, you will also use them cohesively. For instance, to modify the table's structure, you need to get to the Tables collection located off the Catalog object in the ADOX library; however, this Catalog will have its ActiveConnection property set to the Connection object (ADODB). More on this is discussed later in the section “Working with Tables Using ADO.” For now, look at what makes up the individual object models.

The ActiveX Data Objects 2.1 (ADODB) Object Model

The ActiveX Data Objects object model (see Figure 6.2) consists of the following:

• Connection object. Equivalent to the Database object in DAO, this is where most of your work with ADO begins. The objects and collections mentioned after this all come from the Connection object.

• Errors collection/Error object. Identical to the DAO errors collection and error object, this allows developers to manage error handling.

• Command object. This allows you to run a query against a database and return records in a Recordset object, to manipulate a database's structure, or to execute a bulk operation. A collection of parameters is used with the Command object.

• Recordset object. Similar to the DAO Recordset object, you can open the Recordset objects as read-only or dynamic. Each Recordset object also has a Fields collection.

Most of the work is done in the ADODB module when you use ADO. Whenever you use recordsets, this is also the object model to use.

The ADO Extensions 2.1 for DDL and Security (ADOX) Object Model

The ADO Extensions 2.1 for DDL and Security object model (see Figure 6.3) consists of the following:

• Catalog object. This is the container for the Tables, Procedures, Views, Users, and Groups listed here.

• Tables collection/Table object. As with the DAO TableDef collection, Tables are the structures of the existing tables in the database. The Table object consists of columns, keys, indexes, and properties. Row returning, non-parameterized queries can be found here.

• Procedures collection/Procedure object. These are stored procedures.

• Views collection/View object. These virtual tables consist of tables and other views. You can create views by using the Command object, found in the ADODB object model.

• Users collection/User object. The same as DAO, these are users in the workgroup.

• Groups collection/Group object. The same as DAO, these are groups within the workgroup.

Whenever you're creating new objects in the database, you will be using the ADOX object model for saving the objects and maintaining security information.

Jet and Replication Objects 2.1 (JRO) Object Model

The Jet and Replication Objects 2.1 object model (see Figure 6.4) consists of the following:

• JetEngine object. Analogous to dbEngine in DAO, the JetEngine object allows you to use the CompactDatabase and RefreshCache methods. For more information on the CompactDatabase method, see Chapter 27, “Startup Checking System Routines Using ADO.”

• Replicas collection/Replica object. Within this collection and object are all the objects and commands necessary to perform replication programmatically. To see these objects used, check out Chapter 23, “Welcome to the World of Database Replication.”