OLE DB

OLE DB is the Microsoft strategic system-level programming interface to data across the organization. OLE DB is an open specification designed to build on the success of ODBC by providing an open standard for accessing all kinds of data. ODBC was created to access relational databases. OLE DB is designed for relational and nonrelational information sources, including: mainframe ISAM/VSAM and hierarchical databases; e-mail and file system stores; text, graphical, and geographical data; custom business objects; and more.

OLE DB goes beyond simple data access by partitioning the functionality of a traditional relational database into logical components, and the events needed for those components to communicate. Developers can use these interfaces to define very simple data providers as well as fully relational databases. This is a strategic part of the Microsoft enterprise infrastructure for component-based computing.

OLE DB comprises a set of low-level C/C++ interfaces designed to efficiently build database components. They enable an individual data store to easily expose its native functionality without having to make the data look like relational data if it isn’t. They enable generic, reusable database components to augment the functionality of simpler providers when needed.

Because they are low-level interfaces that deal with pointers, structures, and explicit memory handling for optimizing how data is exposed and shared between components, OLE DB interfaces are not suitable for calling directly from Microsoft Visual Basic or Visual J++.

You can think of OLE DB as being to all types of data what ODBC is to SQL data.

OLE DB is designed as a component technology. Data stores expose the COM interfaces that reflect their functionality, and common components can be built on top of those interfaces to expose more robust data models. OLE DB achieves this componentization by identifying common characteristics between different data providers and services and by defining common interfaces to expose those characteristics.

OLE DB defines a collection of COM interfaces that encapsulate various database management system services. These interfaces enable the creation of software components that implement such services. OLE DB interfaces are designed to help components integrate smoothly so that OLE DB component vendors can bring high-quality OLE DB components to market quickly. In addition, OLE DB includes a bridge to ODBC to enable continued support for the broad range of ODBC relational database drivers available today.

Components can be thought of as the combination of both process and data into a secure, reusable object. As a result, it often makes sense to treat components as both consumers and providers of data at the same time. Since the OLE DB specification is a definition of how databases interoperate at various levels, components built by using OLE DB can behave as a table, even though very complex computing processes can actually occur between the data stores and the consuming applications. This capability will have considerable impact on how multitier applications are assembled.

The following figure illustrates the Universal Data Access architecture. There are three general kinds of database components: data providers, services, and consumers.

Data providers are components that represent diverse sources of data such as SQL databases, indexed-sequential files, spreadsheets, document stores, and mail files. Providers expose data uniformly using a common abstraction called the rowset.

Service providers or services are components that extend the functionality of data providers by implementing extended interfaces where not natively supported by the data store. For example, a cursor engine is a service component that can consume data from a sequential, forward-only data store to produce scrollable data. A relational query engine is an example of a service over OLE DB data that produces rowsets satisfying a Boolean predicate.

Consumers are components that consume OLE DB data. Examples of consumers include high-level data access models such as ADO; business applications written in languages like Visual Basic, C++, or Java; and development tools themselves.

All interactions among components in the previous figure, indicated by bidirectional arrows, can occur across process and machine boundaries through network protocols such as Microsoft Distributed COM (DCOM) or HTTP. Transacted interactions among components are possible via a distributed transaction coordination service such as the one included in Microsoft Transaction Server.

OLE DB defines a hierarchy of four main objects as illustrated in the following figure.

The Data Source object encapsulates functions that identify a particular data provider, verify that the user has the appropriate permissions to connect to the provider, and initialize the connection to a particular data store (for example, a file name or database name).

The Session object defines the transactional scope of work done within a connection.

The Command object encapsulates the functions that enable a consumer to invoke the execution of data-definition or data-manipulation commands such as queries.

Rowset objects provide a common representation of data. They are typically created either directly from a session or as a result of a command execution, but may be generated as the result of other methods that return data or metadata.

Before each OLE DB object is created, the caller has the opportunity to request the capabilities or behavior of the data source that need to be surfaced by the object through its interfaces. This is an important aspect to remember when reading the OLE DB Service Provers section.