OLE DB Leveling

Choosing the Right Interfaces

Abstract

OLE DB defines a comprehensive set of interfaces for accessing a diverse range of data types, located in a variety of data stores. While the OLE DB Programmer's Reference can be intimidating in size, no one provider is expected to support all of the functionality defined in the reference. Providers only expose the interfaces that reflect the natural functionality of their data store. Providers all support a base level of functionality. Above that base level, common service components provide interoperability through generic implementations of extensions such as scrolling or notifications if the provider doesn't support them.

Introduction — OLE DB as a Component Technology

To meet its goal of providing data access to all types of data in a COM (Component Object Model) environment, OLE DB is designed as a component technology. In OLE DB, data sources expose the interfaces that reflect their functionality, and common components can be built on top of those interfaces to expose more robust data models. To define a component architecture, OLE DB identifies common characteristics between different data providers and services, and defines common interfaces to expose those characteristics. So, for example, while a rowset may be obtained through a number of very different mechanisms, the end result is still a rowset, with well-defined interfaces, methods and characteristics. With OLE DB, navigating the result of a complex multi-table join is no different than navigating the results of an opened text file containing tabular data. Defining common interfaces in this manner allows components to more efficiently augment the individual data provider's native functionality.

An OLE DB provider exposes OLE DB interfaces over some type of data. OLE DB providers include everything from a full SQL DBMS to a text file or data stream. Obviously these data providers have different functionality, and it's important not to limit that functionality. But at the same time it's not reasonable to expect all providers that expose simple tabular data to implement a full-blown query engine as well.

Once the base functionality is defined, the next step is to view the additional functionality as incremental additions to this base functionality. Thus, the more sophisticated providers can expose these advanced features in addition to the base level interfaces. Furthermore, individual service components can be built to implement these features on top of the simpler providers.

Consumers

Developers writing OLE DB consumers can choose their level of interoperability with OLE DB providers. Consumers may be written to consume a specific provider, in which case they are designed to be aware of the functionality of the provider. Or they may be written to consume generic providers. In order to consume generic providers, the consumer may do one of the following:

• Consume a minimum set of functionality and work with all OLE DB providers.
  
  
• Consume a higher level of functionality and query the provider for support of extended functionality.
  
  
• Consume a higher level of functionality and invoke service components to implement missing functionality, where such service components are available.

Base Consumer Functionality

The following table describes the minimum level of functionality that a consumer can expect to be supported when talking to any OLE DB provider. The table is broken into three columns:

• Object – Lists the OLE DB object that supports the interface or behavior.
  
  
• Base Interfaces – Lists the functionality available over any OLE DB provider.
  
  
• Updatable – Lists the minimum functionality available over any OLE DB provider that supports updating data. Providers not supporting this complete set of functionality are considered read-only providers.

Table 1 – Base Consumer Interfaces

¹These interfaces are always supported by common components in the SDK. They are never implemented directly by providers.

²Support for IDBAsynchStatus does not require that the provider support any operations asynchronously.  In the non-asynch case, the provider would simply block when creating or initializing the object, and return a completion status whenever GetStatus was called.

³DBPROP_INIT_PROMPT is required if any initialization properties are required in order to connect to the provider. If calling Initialize() succeeds on a freshly created Datasource, the provider does not need to support this property.

Providers

Providers support the native functionality of the data which they expose. However, in order to be consumed by generic consumers, providers must be able to support at least the minimum base consumer functionality defined in the previous table. You can develop a provider to support the minimum level of functionality in one of three ways:

• If your data is simple, cached data, use the OLE DB Provider Writer's Toolkit to implement a provider in Microsoft® Visual Basic®, Microsoft® Visual J++™, C, or C++.
  
  
• Implement the minimum provider functionality defined in section 2.1 directly in C or C++, and rely upon service components to implement the additional functionality required for the base consumer functionality.
  
  
• Implement at least the functionality defined in both section 2.1 and section 2.2 directly in C or C++.

In addition, providers may expose interfaces for the extended functionality described in the next section.

All providers must be either apartment or free threaded, and must support aggregation of the DataSource, Session, and Rowset. If applicable, providers must support the aggregation of the Command and View objects.

Minimum Provider Functionality

It's important for provider writers to implement the full set of interfaces that apply to their particular type of data. At a minimum, the provider must implement the interfaces and behavior listed in Table 2 to be considered a generic OLE DB provider. Providers implementing the minimum provider functionality can rely on common service components available in the SDK to implement the  base consumer functionality, as shown in Figure 1.

Figure 1

Table 2 – Minimum Provider Interfaces

¹DBPROP_INIT_PROMPT is required if any initialization properties are required in order to connect to the provider.  If calling Initialize() succeeds on a freshly created Datasource, the provider does not need to support this property.

Supporting an interface means supporting all methods within that interface. No methods return E_NOTIMPL.

Supporting a property means supporting the setting of and associated behavior of all possible values for a property.

Supporting the required rowset properties means that setting any combination of the required properties must yield a rowset that reflects at least those properties. It does not mean that those properties are always true for any rowset if the property has not been requested by the user.

Base Providers

Providers that implement the full set of base interfaces can be consumed by general consumers without the support of additional service components, as shown in Figure 2.

Figure 2

Providers implementing the following functionality in addition to the minimum provider functionality are consumed as base providers:

Table 3 – Full Interfaces for Base Providers

¹Providers that support the property DBPROP_CANSCROLLBACKWARDS must also support the property DBPROP_CANFETCHBACKWARDS.

Extended Interfaces

General purpose providers may support additional functionality. It is advantageous that providers support as many extended interfaces as apply to their particular type of data.

In addition to common interface extensions, providers may expose specialized interfaces for the following sets of extended functionality:

• Rowset Processing – Exposed by providers that support native filter or sort capabilities.
  
  
• Commands – Exposed by providers that can execute more sophisticated queries or statements.
  
  
• Transactions – Exposed by providers that can support transactional capabilities.
  
  
• Index Navigation – Exposed by providers built on indexed data to expose index functionality to service components such as query processors. These interfaces are generally not directly consumed by OLE DB consumers other than service components.

Table 4 – Extended Interfaces

¹Extended functionality that may be exposed by providers which support Rowset Processing.

²Extended functionality that may be exposed by providers which support Commands.

³Extended functionality that may be exposed by providers which support Index navigation.

Generic consumers must be prepared for providers that don't support the extended interfaces. Consumers can handle such providers in several different ways:

• The consumer can invoke common services to implement extended functionality, where such service components are available.
  
  
• The consumer can implement extra code within the application to compensate for missing functionality.
  
  
• The consumer can reduce the functionality available to the user based on missing functionality in the provider.
  
  
• The consumer can return an error indicating that the provider is not capable of supporting required functionality.