As discussed earlier, ADO is a data-access object model that provides a programming
interface for the OLE DB standard, which in turn is an implementation of Microsoft's
Universal Data Access model.
For those who have experience with previous data-access object
models in VB, the main points of comparison between ADO and the earlier data access
models are as follows:
-
ADO's object hierarchy is flatter than the object hierarchies of previous
models (DAO and RDO). ADO provides fewer object classes than earlier models, and
most objects can be instantiated directly by the programmer instead of having to be
instantiated through other objects.
The DAO Recordset object, for example, had to be instantiated through a Database object.
The ADO Recordset object may be instantiated independently of any other object, and then
attached to a Connection or Command object—or you can open the Recordset by calling methods
of the Connection and Command objects.
Making objects less dependent on each other has interesting and useful consequences
besides just conceptual clarity: As a consequence of the example just given, you can create
an ADO Recordset object that never has to be connected to an existing data source—and
you can therefore use such a disconnected Recordset to track and maintain virtual
data created entirely within your application or to maintain data from a database offline.
-
ADO provides the programmer more opportunities to finetune the data cursor of a Recordset.
A data cursor (or just a "cursor") represents a set of resources initiated
by a data connection that provides a connection to a specific row in a set of data. The
data cursor can change position to point to a different row of data. ADO enables
you to directly specify where the cursor is implemented (client or server side) and
several different types of cursors.
-
ADO provides better overall performance than earlier object models.
-
ADO is more resource-efficient than earlier object models.
-
ADO provides more universal data access, due to the universal nature of its underlying
standard, OLE DB.
Following are the objects exposed in the ADO object model:
-
Connection object. Specifies information about the physical connection with a data
source.
-
Command object. Stores information about actions performed on the data, such as data
modification and retrieval. You can use a Command object to execute actions on the
data or to return data from the server in a Recordset object.
-
Recordset object. Provides a rich selection of properties, events, and methods to expose
data in a field-row format, and thus allows you to programmatically traverse, examine,
and manipulate specific fields in specific rows of data.
-
Parameters collection of the Command object (made up of Parameter objects). Contains
information about parameter values that are passed by a Command object.
-
Fields collection of the Recordset object (made up of Field objects). Contains information
about field structure and content of the data in a Recordset object.
-
Properties collection (made up of Property objects). Contains information about provider-specific
properties of Command and Parameter objects.
-
Errors collection of the Connection object (made up of Error objects). Contains information
about the most recent error that occurred when attempting an ADO operation.
The rest of this chapter discusses how to use ADO at various levels, beginning
at a very automated level and ending with lower-level manipulation in code of the object model and
of SQL data providers.
NOTE - DAO Performs Better Than ADO When Accessing Jet
Databases: When accessing Jet databases (that is, MS Access), DAO will perform better
than ADO, because DAO was optimized for Jet.
<<
Previous | Contents
| Next >>
