ADO Programming Model in Detail
The following are key elements of the ADO programming model:
- Connection
- Command
- Parameter
- Recordset
- Field
- Error
- Property
- Record
- Stream
- Collection
- Event
Connection
You gain access from your application to a data source 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, such as Microsoft Internet Information Services (IIS).
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 implicitly with the Microsoft OLE DB Remoting Provider. (Please see Step 2 of the RDS Tutorial for an example of invoking RDS via the OLE DB Remoting Provider.)
The data source that is the target of a connection may be specified with a connection string or a Uniform Resource Locator (URL).
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, or 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.
The Recordset is the primary means of examining and modifying data in the rows. The Recordset object allows you to:
- Specify which rows are available for examination.
- Traverse the rows.
- Specify the order in which the rows may be traversed.
- Add, change, or delete rows.
- Update the data source with changed rows.
- Manage the overall state of the Recordset.
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 or service provider, and exist only while that provider is being used.
The object model embodies a property as a Property object.
Record
Not all data sources exist as tables in a database. Information storage systems, such as file and e-mail systems, consist of container and content components. A container may hold content or other, subordinate containers.
In a file system, the containers and contents are directories and files; in an e-mail system, the containers and contents are folders and messages.
The object model embodies a container or content as a Record object. Furthermore, a row of a Recordset may be embodied as a Record object.
The Record object provides the means to:
- Copy, delete, or move the item it represents.
- Create a new Record suitable for representing items such as a directory or file, or a row of a Recordset.
A Record object is used in conjunction with other ADO objects, such as the Connection and Recordset objects. However, a Record object is designed to solve a different set of issues than the ADO objects described in the Basic ADO Programming Model. See Records and Streams for more information.
Stream
The content of an information storage system, such as a file in a file system, consists of a stream of bytes. Also, a buffer in memory consists of a stream of bytes.
The object model embodies a stream of bytes as a Stream object.
The Stream object provides means to:
- Read or write a series of bytes, or lines of text.
- Populate itself from, or persist itself to, a file.
A Stream object is used only in conjunction with the Record object. A Stream object is designed to solve a different set of issues than the ADO objects described in the Basic ADO Programming Model. See Records and Streams for more information.
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 property either by name, as a text string, or by ordinal, as an integer number.
ADO provides four types of collections:
- The Connection object has the Errors collection, which contains all Error objects created in response to a single failure involving the data source.
- The Command object has the Parameters collection, which contains all Parameter objects that apply to that Command object.
- The Recordset and Record objects have the Fields collection, which contains all Field objects that define the columns of that Recordset object.
- In addition, the Connection, Command, Recordset, and Field objects all have the Properties collection, which contains all the Property objects that apply to their respective containing objects.
ADO objects possess properties in which you set or retrieve values with common data types like INTEGER, CHARACTER, or BOOLEAN. However, it is 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
Events are notifications that certain operations are about to occur, or have already occurred. You can use events 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. Several operations 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.
For more information about events, see ADO Event Model, Synchronous and Asynchronous Operations.