ADO Programming Model Details
The following elements are key parts in the ADO programming model:
Connection Command Parameter Record Set Field Error Attribute Collection Event
connection
With "connection", you can access the data source from the application, the connection is the environment necessary to exchange data. The application can access the data source directly (sometimes referred to as a double system) or indirect (sometimes referred to as a three-layer system) as the medium as the medium, such as Microsoft® Internet Information Server.
The object model uses the Connection object to make the connection concept avatar.
"Transaction" is used to define the beginning and end of a series of data access operations that occur during the connection. ADO can clarify changes or successful changes in the operation in the transaction, or have not occurred at all.
If the transaction is canceled or its operation fails, the final result will seem that the operation in the transaction has not occurred, and the data source will remain the state before the transaction begins.
The object model cannot clearly reflect the concept of transactions, but in a group of Connection object methods.
ADO accesses data and services from OLE DB providers. The Connection object is used to specify a special provider and any parameters. For example, a remote data service (RDS) can be explicitly called, or implicitly called via "Microsoft Ole DB Remoting Provider". (See the RDS tutorial to call RDS second step by "MS Remote Provider")
command
The "command" emitted by the established connection can operate the data source in some way. In general, the command can add, delete, or update data in the data source, or retrieve data in the form of rows.
Object models reflect command concept with Command objects with Command objects. The Command object enables the ADO to optimize the execution of the command.
parameter
Typically, the variable part required by the command is "parameter" can be changed before the command is released. For example, you can repeat the same data retrieval command, but each time you can change the specified search information.
Parameters are very useful for commands that perform their behaviors Similar functions, so you know what the command is doing, but you don't have to know how it works. For example, a bank transfer command can be issued, from one party to the other party. You can set the amount of payee to the parameter.
Object models use parameter objects to reflect parameters concept.
Record set
If the command is a query that returns data in the table (row return query), these rows will be stored locally.
The object model refers to the storage as a Recordset object. However, there is no object that represents only a single RECORDSET line only.
The recordset is the most important method for checking and modifying data in the row. Recordset objects are used in:
Specifies the rows that can be checked. Mobile line. Specifies the order of the mobile line. Add, change, or delete rows. Update the data source by changing the line. Manage the overall status of the Recordset.
Field
A record collection line contains one or more "fields". If the record set is regarded as a two-dimensional grid, the field will be arranged to "column". Each field (column) contains the properties of the name, data type, and value, which is in this value that contains real data from the data source.
The object model reflects fields in the field object.
To modify the data in the data source, you can modify the value of the Field object in the record collection line, and the change to the record set is ultimately transmitted to the data source. As an option, the transaction management method of the Connection object can reliably guarantee that the changes are all successful, or all failed.
error
Error can occur in the application at any time, usually due to the operation of the connection, execution command, or some state (for example, trying to use a recordset without initialization).
The object model reflects an error in Error object.
Any given error generates one or more Error objects, and the resulting error will give up the previous ERROR object group.
Attributes
Each ADO object has a set of unique "properties" to describe or control the behavior of the object. There are two types of properties: built-in and dynamic. The built-in attribute is part of the ADO object and is available at any time. Dynamic properties are added by the special data provider to the properties of the ADO object, only when the provider is used.
The object model reflects attributes in a Property object.
set
ADO provides a "collection", which is convenient to include object types of other special type objects. Use the collection method to retrieve the objects in the collection according to the name (text string) or serial number (integer).
ADO provides four types of sets:
The Connection object has an Erroors collection that includes all Error objects created for a single error associated with the data source. The Command object has a parameters collection that contains all Parameter objects that are applied to the Command object. The Recordset object has a Fields collection that contains all Field objects that define the Recordset object column. In addition, both Connection, Command, Recordset, and Field objects have a Properties collection. It contains all Property objects that belong to each containing objects.
The ADO object has an attribute that can set or retrieve values such as "Integer", "Character", or "Boolean" that can be used thereon. However, it is necessary to see some properties as the return value of the data type "Collection Object". Correspondingly, the collection object has a method of storing and retrieving other objects suitable for this collection.
For example, it is considered that the Recordset object has a Properties property that can return a collection object. This collection object has a method of storing and retrieving a Property object that describes the Nature of the Recordset.
event
"Event" is a notification of certain operations that will happen or already happen. Under normal circumstances, the available events can be used efficiently to write applications that contain several asynchronous tasks.
The object model cannot explicitly reflect events, which can only be expressed in the event handler routine.
The event handler called before the operation is started to check or modify the operational parameters, then cancel or allow the operation to be completed.
The event handler called after the operation is completed, notifications after the asynchronous operation is completed. Multiple operations can be selected asynchronously after enhancing. For example, an application for starting an asynchronous recordset.open operation will be a notification to perform the completion event at the end of the operation.
For more information on events, see the ADO event model and asynchronous operation.
