To view a printable version of this article in a PDF viewer,
click here for PDF.
This article provides an overview of ActiveX® Data Objects (ADO), its data-binding features, and how those features are implemented in FarPoint Technologies
You might want to read this article if you own FarPoint products and use their data binding features. Throughout this article, we assume that you are familiar with FarPoint controls, the Microsoft® Visual Basic® development environment, and the basic principles of data binding.
Introduction to ADO
ADO provides a new and powerful means of accessing data stored in databases. As a single, high-level technology for accessing all types of databases, ADO is simpler and more efficient to use than the two older data access technologies, DAO (Data Access Objects) and RDO (Remote Data Objects). ADO combines the functionality of DAO and RDO into one interface and provides even more features.
Rather than having to choose DAO or RDO depending on the type of database you need to access, you can use ADO to access any type of database or file. For example, while DAO can connect to Microsoft Access .MDB databases, ADO can access HTML, plain text, Internet, spreadsheet, and e-mail files, as well as .MDB and other types of databases.
The ADO Data Model
ADO is a language-neutral object model that lets you manipulate data accessed by an underlying OLE DB provider. (An OLE DB provider is a data manager that interfaces directly with a database. For example, Microsoft Jet is the data manager on which Microsoft Access is built.)
ADO's object model is simpler than DAO's, containing fewer objects and more properties, methods, and events, and combining much of DAO's functionality into single objects.
Many of the objects in the ADO data model are similar to RDO objects, but with enhanced functionality. For example, ADO's Recordset object contains records returned from a database plus the cursor for those records. (A cursor helps manage and manipulate a set of data.) The Recordset object is similar to RDO's rdoResultset object. With ADO, however, you can open a Recordset object without explicitly connecting to the database source. And if you do connect to the database, you can open multiple Recordset objects on the same connection.
You can learn more about the ADO data model from the references listed in
Where can I find out more about ADO?.
Do I have to use ADO?
You do not have to use ADO to bind FarPoint controls to databases right now, but you might want to do so. ADO, DAO, and RDO are different systems for providing data binding in your applications. You will need to decide which system best suits your needs, and use FarPoint Technologies' products according to which data-binding system you choose.
For you, this will mean that you have a choice of how to bind controls to databases:
- The "old" method that uses DAO or RDO
- The new method that uses ADO
How did ADO come about?
DAO, coupled with the Jet data manager, is currently the most widespread method of desktop data access. However, DAO is restricted to working with .MDB files (created with Access) and with ISAM files (such as those created with Paradox and FoxPro® databases). RDO is currently used for accessing data over a network, but is restricted to working with relational ODBC sources.
ADO is the successor technology to DAO and RDO. ADO goes a step further than either DAO or RDO by being able to gather data from legacy sources and from non-relational data (such as e-mail and HTML pages).
ADO is Part of the UDA Strategy
ADO is part of Microsoft's Universal Data Access (UDA) paradigm, a new strategy to access data in its current location and format using a single, high-level data access model.
Using UDA tools prevents the expensive and often impractical task of gathering data from various types of databases into a single data store. Also, since UDA is based on open industry specifications, you are not required to commit to a single vendor's products.
The following UDA tools are available as Microsoft Data Access Components (MDAC):
| UDA Tool
|| ActiveX Data Objects
The interface you use to access data (ADO then uses the other UDA tools)
|| Remote Data Service
Application that allows data access across a network
|| Open DataBase Connectivity
Protocol that allows access to a variety of database types
| OLE DB
|| Object Linking and Embedding DataBase
Application that allows access to data stored in both relational and non-relational formats
Together, these tools enable you to access just about any data source, all through the ADO interface.
What will happen to DAO?
DAO technology will be around for many more years. Several new DAO tools are included with the Visual Basic 6.0 development system, as well as a new Jet version. Microsoft Access itself uses Jet and DAO. Ultimately, though, all applications will move to ADO, as Microsoft has stated that, as of the Visual Studio® 6 development system, ADO is the standard data access object model for Microsoft tools.
Data Binding Differences
This section describes the differences between the "old" data binding technologies (DAO and RDO) and the "new" data binding technology (ADO) for Visual Basic users. Each technology uses a different Visual Basic data control to connect to a database, retrieve data, and link the data to a bound control on a form.
When you bind a control to a database using DAO, the bound control uses the Data control to access the database. The Data control manages how your control accesses the database, and you are limited by the Data control's limitations. For example, you can only bind your control to a database at design time, not at run time.
Similarly as for DAO, when you bind a control to a database using RDO, the bound control uses the Remote Data control to access the database.
When you bind a control to a database using ADO, the bound control uses the ActiveX Data Objects control (the "ADO data control," or ADODC) to access the database. The ADO data control, in turn, uses the OLE DB provider to gain universal access to the data source. This model provides you the opportunity to bind your control to databases dynamically, at run time. For example, you can set up database access using the OLE DB provider and naming the database source. Then, when needed, yo