Conceptual Programming Models in OLE DB

OLE DB Programmer's Reference

OLE DB is consistent with a general model of how applications access data. The model assumes the data is not directly accessible by the application but resides in some separate data store, such as a file or e-mail system, a database, or a resource on the Internet.

The application requests information from an intermediary that returns a copy of the desired data to the application. Although different data stores have different native means to access their information, the intermediary presents a single, consistent means of access to the application.

Data delivered to the application is held in a cache, which is used to locate, examine, and manipulate items of data. Furthermore, the cache facilitates adding new data items and modifying or deleting existing ones. If appropriate, any changes made in the cache are written back to the data store.

Basically, in this model, an application retrieves and optionally updates data in a data store with the help of the intermediary; that is, a consumer (the data access application) accesses data from a data store with the help of a provider (the intermediary). The concept of consumer and provider is fundamental to OLE DB and is the context in which the reader should view all descriptions of OLE DB technology.

Note   Described in COM terms, an OLE DB consumer is any piece of system or application code that consumes an OLE DB interface. This includes OLE DB components themselves. An OLE DB provider is any software component that exposes an OLE DB interface.

OLE DB formalizes the general model with a programming model—the series of tasks that must be performed by a consumer to access, or a provider to deliver, data. OLE DB expresses the programming model by using an object model—the set of COM objects that accomplish the tasks in the programming model.

The COM objects in the object model are manipulated through their interfaces, each of which describes a portion of the functionality necessary to access data. The interfaces are like the two faces of a coin: Developers writing providers map the native functionality of specific data stores to the functionality defined by the interfaces; developers writing consumers invoke the functionality exposed by the interfaces to access the data.

The availability of interface functionality is said to be provider-specific because the availability depends on whether a given provider is able to implement all the defined functionality. Consumers can request a list of the provider's capabilities at run time.

Providers contain programming logic that may augment the native functionality of a data store. Not only can providers supply data, but they can supply services—such as resource pooling and automatic transaction enlistment—through OLE DB interfaces.

Finally, service providers—such as the Remoting Provider, Data Shaping Service, and Persistence Provider—supply services to data providers, such as accessing data on remote machines, restructuring cached data, and locally saving and restoring cached data.

Cotypes as Object Definitions

A cotype is a way to define a group of COM objects, such as rowsets or commands, that have similar characteristics. All COM objects that belong to a particular cotype must expose the mandatory interfaces in that cotype. In addition, they can expose the optional interfaces in the cotype and any interfaces not in the cotype. The following example, which defines the cotype for the data source object, indicates whether the implementation of a specific interface is mandatory or optional.

CoType TDataSource {    [mandatory]   interface IDBCreateSession;    [mandatory]   interface IDBInitialize;    [mandatory]   interface IDBProperties;    [mandatory]   interface IPersist;    [optional]    interface IConnectionPointContainer;    [optional]    interface IDBAsynchStatus;    [optional]    interface IDBDataSourceAdmin;    [optional]    interface IDBInfo;    [optional]    interface IPersistFile;    [optional]    interface ISupportErrorInfo; }

Object Hierarchy

The objects in OLE DB are created in a hierarchy. That is, higher-level objects explicitly or implicitly create lower-level objects. The highest-level object in the hierarchy is created with the COM API routine, CoCreateInstance. Each successive object uses its own interface methods to create subsidiary objects.

Properties

OLE DB properties qualify general functionality, making the functionality specific. The value of a property either represents the state of an attribute of a data source object or service or controls the behavior of a method or service.

OLE DB supports getting or setting arrays of properties in a single operation and also supports getting a list of properties supported by a provider, which enables a consumer to determine the provider's capabilities at run time. Options indicate whether setting each property is required or optional, and status flags indicate whether each property was set successfully. Each property has a value, a type, a description, a read/write attribute, and, for rowset properties, an indicator of whether it can be applied on a column-by-column basis.

Event Notifications

OLE DB uses an ActiveX® controls notification model to implement notifications among OLE DB providers and consumers. Notifications are used by groups of cooperating consumers sharing a rowset. All consumers and rowset-generating actions are assumed to be working within the same transaction. Local notifications enable cooperating consumers sharing a rowset to be informed about actions on the rowset performed by their peers.

For example, consider a form containing two data controls, one displaying data in a grid and the other displaying data as a two-dimensional histogram. Both controls receive their data from the same rowset and operate individually as consumers of the rowset. An end user can send an update to the rowset through the grid control. Notifications enable the other control to be informed of this change as it occurs, giving it the opportunity to update the histogram as appropriate and ultimately providing a consistent view of the data within the form.

For more information about notifications, see Chapter 12: OLE DB Object Notifications.

The Basic OLE DB Programming Models

For a simplified conceptual understanding, consider OLE DB as having two programming models: the "Rowset" and "Binder" models. The Rowset Programming and Object Model mirrors the general data access model described in the preceding section, where OLE DB objects are created in a hierarchical fashion. The Binder Programming and Object Model is a type of shorthand, where OLE DB objects are created directly from Uniform Resource Locators (URLs).

1998-2001 Microsoft Corporation. All rights reserved.