MDAC 2.5 SDK - Technical Articles

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. The OLE DB Programmer's Reference can be intimidating in size, but no one data store is expected to support all of the functionality defined in the reference. OLE DB data 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 predicate-based positioning if the provider doesn't support them.

Defining a minimal level of support exposed by all data stores, along with a common set of extended services, means:

• OLE DB data providers are easier to write. They only have to expose the subset of interfaces that reflect native functionality, resulting in the availability of more data available through OLE DB.
  
  
• Applications that consume OLE DB, directly or through ADO, can assume a rich level of functionality because service components provide extended functionality where not supported by the data store.

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 stores expose the interfaces that reflect their native functionality. 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 multitable join is no different than navigating the result of a text file containing tabular data. Defining common interfaces in this manner allows components to more efficiently augment the individual data provider's native functionality.

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

Table 1 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

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

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

Consumers are guaranteed to get the above functionality in one of three ways:

• Data providers written in Visual Basic, Visual J++, C, or C++ by using the OLE DB Simple Provider (OSP) Toolkit automatically support all of the above functionality and more.
  
  
• Data providers natively written in C or C++ can expose the full set of interfaces listed in Table 1.
  
  
• Data providers natively written in C or C++ can implement the minimal provider functionality described in the section "Minimum Provider Functionality" in this paper. They rely upon service components to implement the additional functionality required for the base consumer functionality.

Providers

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.

Providers support the native functionality of the data that they expose. This includes at least the functionality described in the section "Minimum Provider Functionality" in this paper.  Additional interfaces should be implemented as appropriate. If the provider natively supports all of the functionality listed in the section "Base Consumer Functionality," then service components won't be needed to provide the minimal consumer functionality. In addition, providers may expose interfaces for the extended functionality described in the section "Extended Interfaces."

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

Providers must support data conversions to the types returned in IColumnsInfo::GetColumnsInfo or IColumnsRowset::GetColumnsRowset for rowset columns, and ICommandWithParameters::GetParameterInfo for parameters, as well as DBTYPE_WSTR for all column or parameter values other than those described as objects. Providers that support binding to objects as IStream or ILockBytes must also support binding to those columns as ISequentialStream.

Minimum Provider Functionality

It is 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   Base application using service components to talk to a minimum provider

Table 2   Minimum Provider Interfaces

1   Supporting IConnectionPointContainer for IRowsetNotify is not strictly required for OLE DB 2.0 providers to satisfy the minimum requirements for an updatable provider. However, updatable providers are strongly encouraged to expose this connection point as some consumers will be forced to treat providers as read-only if they do not support rowset notifications by exposing the connection point for IRowsetNotify.

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  Base application talking directly to a base provider

Providers implementing the functionality described in Table 3 in addition to the minimum provider functionality are consumed as base providers.

Table 3   Full Interfaces for Base Providers

1   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

1   Extended functionality that may be exposed by providers which support rowset processing.

2   Extended functionality that may be exposed by providers which support commands.

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