لطفا منتظر باشید ...
The Basic OLE DB Architecture
In addition to defining a basic relationship between consumers and providers, OLE DB defines the following components that make up the OLE DB architecture. (Each component is a COM object.)
Enumerators Enumerators search for available data sources. Consumers that are not hardwired for a particular data source employ enumerators to search for a data source to use.
Data source objects These contain the machinery to connect to a data source (such as a file or a DBMS). A data source object generates sessions.
Sessions Sessions represent connections to a database. For example, sessions provide a context for database transactions. A single data source object can create multiple sessions. Sessions generate transactions, commands, and rowsets.
Transaction objects These are used for managing database transactions in order to maintain database security.
Commands Commands execute text commands, such as SQL statements. If the text command specifies a rowset, such as a SQL SELECT statement, the command will generate rowsets. A single session can create multiple commands.
Rowsets Rowsets expose data in a tabular format. A special case of a rowset is an index. Rowsets can be created from the session or the command.
Errors Errors can be created by any interface on any OLE DB object. They contain additional information about an error, including an optional custom error object.
Here's an example of how you might apply these components to create an OLE DB consumer. If you aren't sure where the data source is, you might first use an enumerator to find it. Once you've located a data source, you can create a session with it. The session will let you access the data as rowsets as well as create commands that generate rowsets.
The upside of using the OLE DB architecture is that you get a homogenous way to access heterogeneous data sources. The downside is that you have to implement a bunch of COM interfaces to make that happen. That's why the OLE DB templates exist.
