ActiveX Data Objects

The OLE DB object model exposes functionality through COM interfaces that are not Automation compatible, which means that OLE DB cannot be used directly from many programming languages and tools, including Visual Basic and Microsoft Visual J++. Thus, UDA also defines the application-level programming interface ADO. All ADO interfaces are dual interfaces, so they can be used by any COM-aware programming language or tool. ADO is the recommended way to access data stores in Windows DNA applications.

The ADO object model is shown in Figure 3-4. ADO is built on top of OLE DB, so you'll see many similarities to the OLE DB object model. ADO was also designed to be familiar to developers who have used earlier Microsoft data access object models such as Data Access Objects (DAO) and Remote Data Objects (RDO). Unlike DAO and RDO, the ADO object model is not hierarchical. All objects except for Error and Field objects can be created independently. This feature makes it easy to reuse objects in different contexts. It also means that often there are several ways to accomplish a particular programming task.

Figure 3-4. The ADO object model.

NOTE

---

Microsoft has introduced several object models for data access over the years. DAO consists of Automation objects for accessing the Microsoft Jet database engine used by Microsoft Access as well as ISAM and ODBC databases. RDO consists of Automation objects for accessing relational ODBC data sources. These technologies are supported "in-the-box" by Visual Basic 5.0. However, while these technologies will continue to be supported, ADO is where future development efforts will be focused.

The Connection object represents a unique session to a data store. Connection is essentially a combination of the Data Source and Session objects in OLE DB. Connection objects expose an Execute method that lets you perform simple tasks with a minimal amount of effort. Alternatively, Connection objects can be attached to Command and Recordset objects, which also offer methods to access data from the data store.

Command objects in ADO are equivalent to OLE DB Command objects—both provide a way to prepare and execute parameterized commands against the data source. Preparing a command lets you save a processed form of the command that can be executed quickly on demand. A Command object has a Parameters collection, which contains one or more Parameter objects, each representing a command-specific parameter. ADO Command objects are available only when the underlying OLE DB provider implements OLE DB Command objects.

Recordset objects are the heart of ADO. Like OLE DB Rowset objects, they represent tabular data from a data source. Connection and Command methods that return data from the data store return read-only Recordset objects that can be accessed sequentially. More flexible Recordsets can be created directly by the programmer, connected to Connection and optionally Command objects, and populated by calling various Recordset methods. Recordsets support a variety of options for controlling the amount of data retrieved from a data source at a given time. Other available options control the type and duration of locks placed on the underlying data source and specify when updates are applied to the data store.

Recordset objects logically consist of sets of rows and columns. At any given time, a Recordset refers to the set of columns associated with a specific row, called the current row. Individual columns of the Recordset are accessed through its Fields collection, with one Field object for every column. Associated with every Recordset is a cursor. In database terms, a cursor is the software that returns rows of data to an application. The cursor in a Recordset indicates the current position in the Recordset and determines what row will be returned next. ADO supports several cursor types, ranging from simple forward-only cursors, to cursors that let you move to any row, to cursors that let you view changes made by other users as you move through the Recordset.