ActiveXÖ Data Objects (ADO) implements a common programming model for any OLE-DB provider. ADO is built around a set of core functions that all data sources are expected to implement. In addition to this core set of features, ADO can also access the unique features of specific data sources through general OLE-DB service providers. ADO utilizes native OLE-DB data sources, including a specific OLE-DB provider that provides access to ODBC drivers. ADO was designed to replace the need for all other high-level data access methods. ADO can access relational databases, or ISAM, or text, or hierarchical, or any type of data source¾as long as there is an ODBC-compliant data access provider for it.
ADO was first introduced in IIS, where it was used in conjunction with ASP. Its primary benefits are ease of use, high speed, low memory overhead, and minimal disk space requirements, which makes it ideal for server-side scripting. In fact, ADO is the recommended technology for data access for ASP applications. ADO can be called directly from server-side scripts.
In ADO, the object hierarchy is de-emphasized. Unlike earlier data access methods, you no longer need to navigate through a hierarchy to create objects; most ADO objects can be created independently. This allows you greater flexibility in re-using objects in different contexts. It also allows you to create only the objects you need, resulting in fewer ADO objects and a smaller working set. ADO also takes advantage of ODBC 3.0 connection pooling.
What ADO cannot do, however, is provide remote data to the client. In other words, once the data has been retrieved and sent to the browser, the user cannot easily manipulate it or make changes to it within the client application. Data operations¾including filtering and record modifications¾must take place on the server, where the actual data manipulation objects reside.
The ADO objects are, by default, assigned the Apartment threading model in the registry. This model guarantees that each object is allocated a single thread for the life of the object, and all calls to the object execute on the same thread. While this model provides significant improvements over the single- or free-threading models, it also has its performance drawbacks. For instance, if you store Microsoft Data Access Components, like the ADODB.Connection object, in the ASP Session object, it will cause the Web server to enforce a limit of one thread per user session.
If the only database you intend to use with ASP is Microsoft SQL Server (that is, you don't plan to use Microsoft Access .MDB files with ASP) and you create instances of Database Access Components that you store in the Session object, you can enhance performance by changing the threading model for some Database Access Components from Apartment to Both in the registry. To change from Apartment to Both, double-click Makefre15.bat in the ADO installation folder (C:\Program Files\Common Files\System\Ado, by default). To reverse the process, (that is, to change the threading model from Both to Apartment) double-click Makeapt15.bat in the ADO installation folder.
For more information on the recommended threading models to use with the ASP Session object, see Setting Object Scope in the Active Server Pages documentation.
For more information, see the ADO Overview.