The following elements are key parts of the ADO programming model:
Connection
Access from your application to a data source is through a connection, the environment necessary for exchanging data. Your application can gain access to a data source directly (sometimes called a two-tier system), or indirectly (sometimes called a three-tier system) through an intermediary like the Microsoft® Internet Information Server.
The object model embodies the concept of a connection with the Connection object.
A transaction delimits the beginning and end of a series of data access operations that transpire across a connection. ADO ensures that changes to a data source resulting from operations in a transaction either all occur successfully, or not at all.
If you cancel the transaction or one of its operations fails, then the ultimate result will be as if none of the operations in the transaction had occurred. The data source will be as it was before the transaction began.
The object model does not explicitly embody the concept of a transaction, but represents it with a set of Connection object methods.
ADO accesses data and services from OLE DB providers. The Connection object is used to specify a particular provider and any parameters. For example, Remote Data Service (RDS) can be invoked explicitly or it can be invoked implicitly with the "MS Remote" provider. (Please see the RDS Tutorial for an example of invoking RDS via the "MS Remote" provider in step 2.)
Command
A command issued across an established connection manipulates the data source in some way. Typically the command adds, deletes, or updates data in the data source, or retrieves data in the form of rows in a table.
The object model embodies the concept of a command with the Command object. The existence of a Command object gives ADO the opportunity to optimize the execution of the command.
Parameter
Often, commands require variable parts, parameters, that can be altered before you issue the command. For example, you could issue the same data retrieval command repeatedly, but each time vary your specification of the information to be retrieved.
Parameters are especially useful for executing commands that behave like functions. In this case you know what the command does, but not necessarily how it works. For example, you issue a bank transfer command that debits one account and credits another. You specify the amount of money to be transferred as a parameter.
The object model embodies the concept of a parameter with the Parameter object.
Recordset
If your command is a query that returns data as rows of information in a table (that is, it is a row-returning query), then those rows are placed in local storage.
The object model embodies this storage as a Recordset object. However, there is no object that represents a single row of a Recordset.
The Recordset is the primary means of examining and modifying data in the rows. The Recordset object allows you to:
Field
A row of a Recordset consists of one or more fields. If you envision the Recordset as a two-dimensional grid, the fields line up to form columns. Each field (column) has among its attributes a name, a data type, and a value. It is this value that contains the actual data from the data source.
The object model embodies a field as a Field object.
In order to modify data in the data source, you modify the value of Field objects in Recordset rows. Ultimately, changes to a Recordset are propagated to the data source. As an option, the transaction management methods on the Connection object can guarantee that the changes succeed or fail in unison.
Error
Errors can occur at any time in your application, usually as the result of not being able to establish a connection, execute a command, or perform an operation on an object in a suitable state (for example, attempting to use a Recordset object that has not been initialized).
The object model embodies an error as an Error object.
Any given error produces one or more Error objects. The next error that occurs will discard the previous set of Error objects.
Property
Each ADO object has a set of unique properties that either describe or control the behavior of that object.
There are two types of properties: built-in and dynamic. Built-in properties are part of the ADO object and are always available. Dynamic properties are added to the ADO object's Properties collection by the underlying data provider, and exist only while that provider is being used.
The object model embodies a property as a Property object.
Collection
ADO provides collections, a type of object that conveniently contains other objects of a particular type. The objects in the collection can be retrieved with a collection method either by name, as a text string, or by ordinal, as an integer number.
ADO provides four types of collections:
ADO objects possess properties where you set or retrieve values with common data types like INTEGER, CHARACTER, or BOOLEAN. However, it's useful to think of certain properties as returning values of data type "COLLECTION OBJECT." The collection object, in turn, has methods to store and retrieve other objects suitable for the collection.
For example, you can think of the Recordset object as having a Properties property that returns a collection object. That collection object has methods to store and retrieve Property objects describing attributes of that Recordset.
Events
ADO 2.0 introduces the concept of events to the programming model. Events are notifications that certain operations are about to occur, or have already occurred. You can use events, in general, to efficiently orchestrate an application consisting of several asynchronous tasks.
The object model does not explicitly embody events, but represents them as calls to event handler routines.
Event handlers called before the operation starts offer you the opportunity to examine or modify the operation parameters, then either cancel or allow the operation to complete.
Event handlers called after an operation completes notify you at the completion of an asynchronous operation. ADO 2.0 introduces several operations that have been enhanced to optionally execute asynchronously. For example, an application that starts an asynchronous Recordset.Open operation is notified by an execution complete event when the operation concludes.
There are two families of events: