The OLE DB object model comprises the following objects or components. The first four objects or components listed (data sources, sessions, commands, and rowsets) allow you to connect to a data source and view it. The rest, starting with accessors, relate to working with the data when it is displayed.
Data source objects allow you to connect to a data source such as a file or DBMS. A data source object creates and manages the connection and contains permissions and authentications information (such as login name and password). A data source object can create one or more sessions.
A session manages a particular interaction with the data source to query and retrieve data. Each session is a single transaction. A transaction is an indivisible work unit defined by the ACID test. For a definition of ACID, see Transactions.
Sessions perform important tasks such as opening rowsets and returning the data source object that created it. Sessions can also return metadata, or information about the data source itself (such as table information).
A session can create one or more commands.
Commands execute a text command such as a SQL statement. If the text command specifies a rowset, such as a SQL SELECT statement, the command creates the rowset.
A command is simply a container for a text command, which is a string (such as a SQL statement) passed from a consumer to a data source object for execution by the provider's underlying data store. Typically, the text command is a SQL SELECT statement (in which case, because SQL SELECT specifies a rowset, the command automatically creates a rowset).
Rowsets expose data in tabular format. An index is a special case of a rowset. You can create rowsets from the session or the command.
Schemas contain metadata (structural information) about a database. Schema rowsets are rowsets that contain schema information. Some OLE DB providers for DBMS support schema rowset objects. For more information about schema rowsets, see Obtaining Metadata with Schema Rowsets and .
A view object defines a subset of the rows and columns from a rowset. It contains no data of its own. View objects cannot combine data from multiple rowsets.
Only OLE DB uses the concept of accessors. An accessor describes how data is stored in a consumer. It contains a set of bindings (called a column map) between rowset fields (columns) and data members that you declare in the consumer.
Transaction objects are used when committing or aborting nested transactions at other than the lowest level. A transaction is an indivisible work unit defined by the ACID test. ACID stands for:
Atomicity: cannot be divided into smaller work units.
Concurrency: more than one transaction can occur at a time.
Isolation: one transaction has limited knowledge about changes made by another.
Durability: the transaction makes persistent changes.
Enumerators search for available data sources and other enumerators. Consumers that are not customized for a particular data source use enumerators to search for a data source to use.
A root enumerator, shipped in the Microsoft Data Access SDK, traverses the registry looking for data sources and other enumerators. Other enumerators traverse the registry or search in a provider-specific manner.
Any interface on any OLE DB object can generate errors. Errors contain additional information about an error, including an optional custom error object. This information is contained in an HRESULT.
Notifications are used by groups of cooperating consumers sharing a rowset (where sharing means that the consumers are assumed to be working within the same transaction). Notifications enable cooperating consumers sharing a rowset to be informed about actions on the rowset performed by their peers.