ADO 2.5 Object Model

ado| objects

Although two new objects appear in the ADO 2.5 object model, they are basically similar to previous versions. Figure 8-3 shows the relationships between these objects and each object:

If you've used ADO before, you'll notice that there are two new objects in this new version: Stream and record objects. They will be described in detail in chapters 11th and 12.
The Properties collection has been deliberately excluded from figure 8-3, so that you have a clear view of the interaction between several main objects. Later in this chapter, there is a simplified object model that shows the Properties collection.
Let's examine these objects in more detail.

8.2.1 Connection Object
The connection object is the object that enables us to connect to the data store. Only the Connection object can specify the OLE DB provider you want to use, the security details connected to the data store, and any other specific details connected to the data store.
Application Note that you do not have to explicitly create a connection object to connect to the data store. Although you do need to specify connection details, but there are no connection objects, you can create command, Recordset, and record objects as well. If you don't create your own connection object, ADO will implicitly create a connection object for you. If you want to run multiple commands on a provider, you should explicitly create a connection object, which is more efficient than creating a connection for each command you run.
In addition to providing a connection for the data store, the Connection object allows command operations to be performed on the data store. These commands can be structured or stored commands (for example, SQL commands or a stored procedure), and can optionally return some data from the data store.

8.2.2 Command Object
The command object is an object that executes commands on the data store. Can the connection object be able to do so if you see readers here may have questions? Yes, but the connection object is limited in its ability to handle commands, and the command object is created specifically to handle various aspects of the command. In fact, when you run a command from a Connection object, you have implicitly created one.
Sometimes other objects allow you to pass parameters to the command, but you cannot specify any details of the parameters in the Connection object. Use the Command object to allow you to specify precise details (such as data type and length) for parameters (and the return values after the output parameters and commands are executed).
Therefore, in addition to executing commands and getting a series of return records, some additional information provided by the command may be obtained.
Command objects are also useful for commands that do not return any records, such as SQL queries that insert new data or update data.

8.2.3 Recordset Object
The Recordset object is the most commonly used object in ADO because it contains a dataset that is extracted from the data store. We often run commands that do not return data, such as those that add or update data, but in most cases it is likely that a series of records will be made.
The Recordset object is the object that owns the records. You can change (add, update, and delete) records in a Recordset, move records up and down, filter records, display only part of the content, and so on. The Recordset object also contains the Fields collection, fields the filed object in the collection for each field (column) in the recordset.
Whether you are working with data in an ASP page or using Remote Data Services (RDS) to remotely use data, the Recordset object is the object that must be processed.

8.2.4 Record Object
The previous version of ADO 2.5 was useful for working with structured data, such as fetching a recordset from a database, but not being able to handle data that might be different for each row's columns (that is, columns and data types). This is not a problem for SQL data, but what about Web servers and other such data stores for file and messaging systems? We think of these data as semi-structured data, which is structurally poor compared to the recordset, but more structured than the binary data that is commonly used to represent text or images.
Typically, the storage of semi-structured data is organized in a tree-like structure, with nodes, subnodes, and files. For example, imagine a Web site with folders, subfolders, and files. The screen diagram shown in Figure 8-4 shows the Web site of a single machine, in particular a virtual directory named public:

If you are sure you want to model in ADO, you will find this very appropriate for the recordset, possibly the set of nested recordsets. However, note the high brightness display of the directory, which contains different types of files, which have several directories, two ASP files, a text file and a Word document. You can easily map it to a recordset with fields such as name, type, last access time, and so on, unfortunately not so simple. For access permissions, there is a difference between files and directories. For a directory, you need access to the files in the directory, and for a file, you may need to access its contents.
Because of its complexity, a record object is introduced. In the case above, there is a collection of entries with the same attributes, but each entry also has a unique attribute, so you need to use a different method to process the data. Maps a set to a recordset, a single file is mapped to a record, and the corresponding file attribute is mapped to a Fields collection.
This means that you have a recordset that contains six of rows of records. Accessing a separate row in the recordset will give you the properties (fields) of the file, but only the properties that are provided to us, in order to access the contents of the file or directory, you need to use the Record object, which contains the unique properties of the file or directory.       It's difficult to get used to this concept, but don't worry, in chapters 11th and 12 you'll see more examples of the record objects. Only the OLE DB Provider for Internet Publishing uses the Record object since the initial release of Windows 2000. Once Microsoft Exchange 6.0 is released, it becomes an OLE DB provider that provides access to the Exchange database in a similar way using recordsets and records.
8.2.5 Stream Object
Stream object is used to access the contents of a node, such as an e-mail message, or a Web page. Use the Stream object to access the real content of a file or resource. Therefore, combined with the record and Recordset objects, you can access not only the file or email messages on the Web server, but also the appropriate content. This allows you to create a mail client that only uses ADO to access the messaging system. This may not have many advantages, but it means that there is no need to understand the API or object model of the messaging system, reducing the detours in learning.
Another use of stream is XML, which can access a series of data as XML streams (structured or semi-structured).
The stream object is used to process binary data, so it can be used to work with blob-type data, such as images in a database or large text data.
Again, in chapters 11th and 12 of this book you will see more examples of stream objects.

8.2.6 Collection
There are collections in the ADO object library, each of which has 0 or more copies of objects associated with it. You can use the same code structure to traverse these collections.
The syntax in VBScript is:
For all object in Collection
' Do something with object
Next
For example, iterate through the fields set of a Recordset object:
For Each objfield in Rs. Fields
Response.Write objField.Name & "<BR>"
Next
If you select JScript, you can use the enumerator object:
for (Objfield = new Enumerator (Rs. Fields);
!objfield.atend (); Objfield.movenext ())
Response.Write (Objfield.item (). Name + ' <BR> ');
1. Fields collection
The Fields collection has a Field object associated with a recordset or record. For a recordset based on structured data, such as SQL data, the field corresponds to a column in the data and contains the details of the column, such as name, data type, length, and so on. See a lot of examples of fields collections in the next few chapters.
For semi-structured data, the properties of the object correspond to fields. In the 12th chapter you will see more relevant introductions.
2. Parameters Collection
The Parameters collection is used only by the command object to determine the parameters in the stored command. stored procedures in SQL databases frequently use parameters and allow data to be passed in and out of predefined SQL statements. It is useful if you have a parameter that returns information to ADO because it returns more than a recordset from a stored procedure. For example, to consider a complex stored procedure that updates multiple tables and then returns a Recordset, you can display the number of records updated with an output parameter.
Another reason to use parameters is a performance problem, especially if you only need to return a single value from a stored procedure. In this case, there is no need to create a recordset, just save a value so that you do not need to return the recordset, and returning the value of the output parameter is a more efficient method.
In the 9th chapter you will see a detailed introduction to the parameter collection.
3. Error collection
The error collection contains the details of the last ADO or OLE DB Provider error caused by running the command and can only be accessed by the Connection object. This may feel like a limitation because you do not have to explicitly define the connection object, but you can access the implied connection object through the command, Recordset, and the ActiveConnection properties of the Record object. For example:
For each objerror in Rs. Activeconnection.errors
Response.Write Objerror.name & "<BR>"
Next
The error collection is discussed in detail later in this chapter.
4. Properties collection
To avoid confusion, the Properties collection is not shown on the previous object model diagram. Its relationship to the object model is shown in Figure 8-5:

The Properties collection exists because ADO is used to handle many different data stores and has different characteristics. A property is made into a collection that can be dynamically changed according to the data provider. For example, the OLE DB Provider for Jet allows access to jet's special security properties:
Set condb = Server.CreateObject ("ADODB. Connection ")
Condb.open "Dsn=nwind"

Condb.properties ("Jet oledb:database Password") = "Letmein"
The other provider does not have this attribute, so it is unwise to add it to the connection object as a static property. ADO populates the property collection with provider defaults based on the OLE DB provider that is being used.
Although there is a description of the use of the Properties collection, it is not intended to describe the Properties collection in detail in this book. For more information on this collection, see "Professional ADO 2.5 Programming" or "ADO 2.5 programming ' Reference", both of which are published by Wrox.

8.2.7 ADO constant
When using ADO, there are many predefined constants for many options, such as constants that define cursor types and lock types. With languages like Visual Basic or Visual C + +, these constants are used naturally once the ADO type library is referenced. There are two options for different situations in the ASP.
The first way to reference constants is to include them in an ASP file:
<!--#INCLUDE file= "Adovbc.inc"-->
You can either copy the containing file to the local directory, or reference it from the installation directory, and the default path is C:Program FilesCommon Filessystemado (the above file contains the ADO constants for VBScript-for JScript, You should use Adojavas. Inc.). The disadvantage of using this method is that the ASP page becomes too large, because it contains all the constants, many of which are not needed.
You can create your own containing files that contain only the constants you need, but more and more of the functionality of ADO is likely to find that you need to constantly edit and maintain this file.
A better solution is to create a reference to a type library that does not need to include constants in the ASP file and can refer directly to constants:
<!--METADATA type= "typelib" file= "C:Program Files
Common FilesSystemadomsado15.dll "-->
Do not suspect that the name of this DLL is Msado15.dll, which is a correct name, containing the latest version of ADO.
You can include this metadata statement in each ASP file where you need it, or put in a Global.asa file so that each Web page in your application can reference these constants.