Active Data Objects (ADO) enables you to write a client application to access and manipulate data in a database server through a provider. ADOs primary benefits are ease of use, high speed, low memory overhead, and a small disk footprint. This help file is for ADODB, an implementation of ADO optimized for use with Microsoft OLE DB providers, including the Microsoft ODBC Provider for OLE DB.
Active Data Objects (ADO) provides a common programming model for any OLE DB data source; it is essentially a collection of objects that expose the attributes and methods used to communicate with a data source. ADO uses general OLE DB providers to accesse unique features of specific data sources; it also uses native OLE DB providers, including a specific OLE DB provider that provides access to Open Database Connectivity (ODBC) drivers. Designed to replace the need for all other high-level data access methods, ADO can access relational, Indexed Sequential Access Method (ISAM), or hierarchical databases, or any type of data source-as long as there is an ODBC-compliant driver.
ADOs ease of use, speed, and low memory overhead make 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 or from business components.
Unlike earlier data access methods, ADO does not require navigation through a hierarchy to create objects; most ADO objects can be created independently, which allows greater flexibility in reusing objects in different contexts and reduces memory consumption. ADO also takes advantage of ODBC 3.0 connection pooling for ODBC data sources, and session pooling for OLE DB providers. This eliminates the need to continuously create new Connection objects for each user, which is very resource intensive.
What ADO cannot do, however, is provide remote data to the client. 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.
