Export (0) Print
Expand All

OLE DB Provider Templates

Introduction

OLE DB is an important part of Microsoft's Universal Data Access strategy. The OLE DB design allows high performance data access from any data source. Any tabular data is viewable through OLE DB regardless of whether it came from a database. The flexibility gives you a tremendous amount of power.

As explained in OLE DB Consumers and Providers, OLE DB uses the concept of consumers and providers. The consumer makes requests for data; the provider returns data in a tabular format to the consumer. From a programming perspective, the most important implication of this model is that the provider must implement any call the consumer can make.

What Is a Provider?

An OLE DB provider is a set of COM objects that serve interface calls from a consumer object, transferring data in a tabular format from a durable source (called a data store) to the consumer.

Providers can be simple or complex. The provider can support a minimal amount of functionality or a full-blown production quality provider by implementing more interfaces. A provider can return a table, it can allow the client to determine the format of that table, and it can perform operations on that data.

Each provider implements a standard set of COM objects to handle requests from the client, with standard meaning that any OLE DB consumer can access data from any provider, regardless of language (C++, Basic, and so on).

Each COM object contains several interfaces, some of which are required and some of which are optional. By implementing the mandatory interfaces, a provider guarantees a minimum level of functionality (called compliance) that any client should be able to use. A provider can implement optional interfaces to provide additional functionality. The OLE DB Provider Template Architecture describes these interfaces in detail. (The client should always call QueryInterface to determine if a provider supports a given interface.)

OLE DB Specification Level Support

The OLE DB provider templates support the OLE DB version 2.7 specification. Using the OLE DB provider templates, you can implement a level 0 compliant provider. (For an explanation of level 0, see "Minimum Provider Functionality" in "OLE DB Leveling: Choosing the Right Interfaces" at http://www.microsoft.com/data/oledb/techinfo/oledbleveling2.htm).) The Provider sample, for example, uses the templates to implement a non-SQL (MS-DOS) command server that executes the DOS DIR command to query the file system. The Provider sample returns the directory information in a rowset, which is the standard OLE DB mechanism for returning tabular data.

The simplest type of provider supported by the OLE DB templates is a read-only provider with no commands. Providers with commands are also supported, as are bookmarking and read/write capability. You can implement a read/write provider by writing additional code. Dynamic rowsets and transactions are not supported by the current version, but you can add them if you want.

When Do You Need to Create an OLE DB Provider?

You do not always need to create your own provider; Microsoft provides several prepackaged, standard providers in the Data Link Properties dialog box in Visual C++. The main reason to create an OLE DB provider is to take advantage of the Universal Data Access strategy. Some of advantages of doing so are:

  • Accessing data through any language such as C++, Basic, Visual Basic Scripting Edition, and others. It allows different programmers in your organization to access the same data in the same way, regardless of what language they use.
  • Exposing your data to other data sources such as SQL Server, Microsoft Excel, Access, and others. This can be very useful if you want to transfer data among different formats.
  • Participating in cross–data source (heterogeneous) operations. This can be a very effective way of data warehousing. By using OLE DB providers, you can keep data in its native format and still be able to access it in a simple operation.
  • Adding additional capabilities to your data, such as query processing.
  • Increasing performance of accessing data by controlling how it is manipulated.
  • Increasing robustness. If you have a proprietary data format that only one programmer can access, you are at risk. Using OLE DB providers, you can open that proprietary format to all your programmers.

Read-Only and Updatable Providers

Providers can vary greatly in complexity and functionality. It is useful to categorize providers into read-only providers and updatable providers:

  • Visual C++ 6.0 supported only read-only providers. Creating an OLE DB Provider discusses how to create a read-only provider, and the MyProv sample is an example of a read-only provider.
  • Visual C++ .NET supports updatable providers, which can update (write to) the data store. For information on updatable providers, see Creating an Updatable Provider; the UpdatePV sample is an example of an updatable provider.

For more information, see:

See Also

Data Access | OLE DB SDK Documentation | OLE DB Programmer's Reference

Show:
© 2015 Microsoft