Datasheet

however, this sequence was much simpler. Developers could just create a command object directly, pass-
ing in the connection information and executing it. For simplicity and best practice, most developers
would still create a separate
command object, but for the first time the object could stand alone.
As stated before, ADO was primarily released to complement OLE-DB; however, ADO was not limited
to just communicating with OLE-DB data sources. ADO introduced the provider model, which enabled
software vendors to create their own providers relatively easily, which could then be used by ADO to
communicate with a given vendor’s data source and implement many of the optimizations specific to
that data source. The ODBC provider that shipped with ADO was one example of this. When a devel-
oper connected to an ODBC data source, ADO would communicate through the ODBC provider instead
of through OLE-DB. More direct communication to the data source resulted in better performance and
an easily extensible framework. Figure 1-4 shows this relationship.
Figure 1-4
In addition to being a cleaner object model, ADO also offered a wider feature set to help lure developers
away from DAO and RDO. These included the following:
❑ Batch Updating — For the first time, users enjoyed the capability to make changes to an entire
recordset in memory and then persist these changes back to the database by using the
UpdateBatch command.
❑ Disconnected Data Access — Although this wasn’t available in the original release, subsequent
releases offered the capability to work with data in a disconnected state, which greatly reduced
the load placed on database servers.
❑ Multiple Recordsets — ADO provided the capability to execute a query that returns multiple
recordsets and work with all of them in memory. This feature wasn’t even available in
ADO.NET until this release, now known as Multiple Active Result Sets (MARS).
Application
ADO
ODBC OLE DB
Data Store
9
History of Data Access
03_584375 ch01.qxd 10/28/05 10:49 PM Page 9