Microsoft Corporation
Updated August 11, 1997
The Microsoft® ActiveX™ Data Objects (ADO) programming model represents the best of the existing Microsoft data access programming models. If you are familiar with Data Access Objects (DAO) or Remote Data Objects (RDO), you will recognize the interfaces and will be able to work with them very quickly. You will also notice considerable improvements in the model, and tasks that were awkward in previous models have either been fixed or eliminated from the ADO model.
The ADO objects provide you with the fastest, easiest, and most productive means for accessing all kinds of data sources. The ADO model strives to expose everything that the underlying data provider can do, while still adding value by giving you shortcuts for common operations.
Figure 1 is a diagram showing the interfaces and how they relate to one another.
Figure 1. ADO programming interfaces
Notice that the Command interface is actually optional and may not be supported with some data providers, since some unstructured data providers are not capable of processing text-based command syntax or providing parameterized statements. Since the Recordset object is creatable and the Source property of the Recordset interface may be set to a simple text command (such as a directory name for a file system provider or an SQL statement for a database management system–type (DBMS-type) provider), you can still create Recordsets, even if the provider does not support the Command interface.
All objects in the implementation can be created on their own with the exception of the Error and Field objects. The hierarchy of objects found in previous models is de-emphasized in the ADO model. This allows you greater flexibility in reusing objects in different contexts. For example, you can create a Command object, associate and execute it against one connection, then associate it with a different connection and execute there. This approach also paves the way for you to create specialized objects (that are defined at design time) and temporary, unattached Recordsets.
The Connection interface represents a connection to the data source and allows you to execute commands. To execute any kind of command, you use the Execute method of the Connection interface. If the command returns rows, a default Recordset object is created and returned. To specify a more complex Recordset, you create a new Recordset object, associate it with the Connection, and open the cursor.
The Command interface represents a command (also known as a query or statement) that can be processed by the data source. Commands can return rows or not, and if the provider is capable, can also handle parameters. The Command interface is actually optional in the ADO model since some data providers cannot supply command execution, but the interface is supported if the provider supports commands.
Commands can be simple SQL statements (or some other language the data provider recognizes) or calls to stored procedures in the database. Commands then can be executed using the Command's Execute method, or you can create a Recordset object and associate it with the Command object when opening the cursor.
The Command object includes a collection of Parameter objects, which is described below. If the provider can support commands with parameters, the Parameters collection will contain one parameter object for each parameter in the command. As opposed to past models, you can create Parameter objects and explicitly add them to the Parameters collection, thus allowing you to use well-known parameterized commands to avoid the sometimes very expensive operation of having the provider populate the Parameters collection automatically based on the system catalog.
The Parameter interface represents a parameter of a Command. As noted in the Command description, you can explicitly create Parameter objects and add them to the Parameters collection to avoid the often unnecessary and expensive task of going to the system catalog to automatically populate the parameter binding information.
The Recordset interface is by far the most complex (the others are simplified considerably). This is not surprising, however, since all the cursor functionality is represented in this interface. The Recordset interface looks much as it does in existing models today, but a number of improvements have been made, including removing unnecessary things, adding optional arguments that reduce the number of lines of code for common scenarios, and changing defaults that no longer make sense for today's technologies.
The Field interface represents a column in a Recordset that you can use to obtain values, modify values, and learn about column metadata. This interface is almost identical to past models, but includes some new functionality.
The Error interface represents an error object returned from a data source. This interface is actually optional for the base ADO interface set, since it is only needed when data sources can return multiple interesting errors for a single method call. If a provider does not return multiple errors for a single function call, the provider just raises the error through the normal Component Object Model (COM) mechanisms that all COM servers do when called from languages like Microsoft Visual Basic®.
Currently, you can use ActiveX Data Objects (ADO) in conjunction with the following Microsoft products.
Active Server Pages (ASP) is a feature of Microsoft Internet Information Server version 3.0, which is a component of Microsoft Windows NT® Server 4.0. Active Server Pages provides an environment and components for rapid development of intelligent, dynamic Web server applications. ADO scripts are written with Microsoft Visual Basic, Scripting Edition (VBScript).
Use the CreateObject(ProgID) function on the server object to create new ADO objects.
ADO constants must be declared explicitly because they are not loaded automatically from the type library. The ADO constants are declared in the adovbs.inc file and can be manually inserted into your script.
set rs = server.CreateObject("ADODB.Recordset" )
rs.Open parameters
while not rs.EOF
' Insert your processing code here.
rs.MoveNext
wend
rs.Close
Microsoft Internet Explorer 3.0 supports VBScript. In this environment, you must use the Hypertext Markup Language (HTML) <OBJECT> tag to create an ADO object. You must have a unique identifier (CLSID) for the object you want to create.
<object id=rs
clsid="clsid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</object>
<script language="vbs">
rs.Open parameters
while not rs.EOF
' Insert your processing code here.
rs.MoveNext
wend
rs.Close
</script>