Part 1: Introduction to OLE DB

Part 1 of the OLE DB Programmer's Reference describes the functional advantages of using OLE DB for consistent data access performance across diverse data stores and also provides an in-depth discussion of the primary OLE DB objects, data types, properties, and important programming considerations. This section contains the following chapters:

Chapter 1: Overview of OLE DB
Chapter 2: Data Source and Session Objects
Chapter 3: Commands
Chapter 4: Rowsets
Chapter 5: Updating Data in Rowsets
Chapter 6: Getting and Setting Data
Chapter 7: BLOBs and COM Objects
Chapter 8: Binder Objects and Direct Binding
Chapter 9: Row and Stream Objects
Chapter 10: Index Rowsets
Chapter 11: Integrated Indexes
Chapter 12: OLE DB Object Notifications
Chapter 13: Data Types in OLE DB
Chapter 14: Properties
Chapter 15: Transactions
Chapter 16: Errors
Chapter 17: Asynchronous Processing
Chapter 18: Programming Considerations

OLE DB Programmer's Reference

Chapter 1: Overview of OLE DB

Today, a vast amount of the critical information necessary for conducting day-to-day business is found outside of traditional, corporate production databases. Instead, this information is found in file systems, in indexed-sequential files such as Btrieve, and in personal databases such as Microsoft� Access and Microsoft Visual FoxPro�; it's found in productivity tools such as spreadsheets, project management planners, and electronic mail; and more and more frequently, it's found on the World Wide Web.

To take advantage of the benefits of database technology, such as declarative queries, transactions, and security, businesses have traditionally had to move the data from its original containing system into some type of database management system (DBMS). This process is expensive and redundant. Furthermore, businesses need to be able to exploit the advantages of database technology not only when accessing data within a DBMS but also when accessing data from any other type of information container. To address this need, Microsoft created OLE DB.

OLE DB is a set of Component Object Model (COM) interfaces that provide applications with uniform access to data stored in diverse information sources and that also provide the ability to implement additional database services. These interfaces support the amount of DBMS functionality appropriate to the data store, enabling it to share its data.

OLE DB Programmer's Reference

Conceptual Programming Models in OLE DB

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).

Microsoft OLE DB 2.0 Programmers Reference and Data Access SDK (Microsoft Professional Editions) - page 2