This home page is your starting point for information about the
Microsoft OLE DB database technology and the OLE DB Template
It is important to know that Microsoft provides several
implementations of OLE DB. OLE DB is a set of COM interfaces that
provide uniform access to data in diverse information sources and
The OLE DB templates are C++ templates that make the
high-performance OLE DB database technology easier to use by
providing classes that implement many commonly used OLE DB
interfaces. This template library is divided into consumer templates
and provider templates.
Visual C++ also has wizard support for creating OLE DB starter
In addition, you can use attributes to implement the OLE DB
To learn more about
Using the OLE DB consumer templates (conceptual
OLE DB Consumer Templates
Using the OLE DB provider templates (conceptual
OLE DB Provider Templates
OLE DB templates classes and macros
OLE DB Templates Reference (Visual C++)
OLE DB consumer attributes
OLE DB Consumer Attributes
OLE DB interfaces
OLE DB programmer's reference (in the Windows SDK)
OLE DB templates samples
OLE DB Templates Samples
Data access programming overview (Visual C++)
Data Access Programming
ODBC vs. DAO
Should I Use DAO or ODBC?
ODBC conceptual topics
Open Database Connectivity (ODBC)
Data-bound controls (ADO and RDO) conceptual topics
Data-Bound Controls (ADO and RDO)
OLE DB Programming Overview
What is OLE DB, and what makes it distinct from other database
technologies? OLE DB is a high-performance, COM-based database
technology produced by Microsoft. What sets OLE DB apart from
Microsoft's other database technologies is how it provides Universal
Universal Data Access provides a common way to access
data regardless of the form in which it is stored. In a
typical business situation, a vast amount of information is
stored outside of corporate databases. This information is
found in file systems (such as FAT or NTFS),
indexed-sequential files, personal databases (such as
Access), spreadsheets (such as Excel), project planning
applications (such as Project), and email (such as Outlook).
Accessing this data using the various associated
applications presents a major bottleneck in workflow or at
least an annoyance. Most companies find themselves in this
situation and deal with the problem by consolidating the
information in a database management system (DBMS). However,
such a move is expensive, time consuming, and in many cases
The alternative is to develop a Universal Data Access
solution. OLE DB and ADO provide Universal Data Access
capability. Of the two, OLE DB is the more performance
intensive and is recommended for use with Visual C++
Universal Data Access implies two capabilities: the first
is distributed query or uniform access to multiple
(distributed) data sources and the second is the ability to
make non-DBMS data sources accessible to database
The ability to access data
uniformly on multiple (that is, distributed) data
sources. The data sources can be of the same type (such
as two separate Access databases) or of different types
(such as a SQL Server database and an Access database).
Uniformly means that you can meaningfully run the same
query on all data sources.
The ability to make non-DBMS data
sources accessible to database applications. Examples of
DBMS data sources include IMS, DB2, Oracle, SQL Server,
Access, and Paradox. Examples of non-DBMS data sources
include information in file systems, email,
spreadsheets, and project management tools.
Consider a scenario in which a sales department needs to
find all email messages received within a one-week period
from customers in a certain area. This query might require a
search on an email application's mailbox file and a search
on an Access table of customers to specify the customers'
names. While Access is a DBMS application, Outlook is not.
OLE DB allows you to develop applications that access
diverse data sources, whether they are DBMS or not. OLE DB
makes universal access possible by using COM interfaces that
support the appropriate DBMS functionality for a given data
source. COM reduces unnecessary duplication of services and
maximized interoperability not only among data sources but
also among other applications.
This is where COM comes in. OLE DB is a set of COM
interfaces. By accessing data through a uniform set of
interfaces, you can organize a database into a matrix of
Based on the COM specification, OLE DB defines an
extensible and maintainable collection of interfaces that
factor and encapsulate consistent, reusable portions of DBMS
functionality. These interfaces define the boundaries of
DBMS components such as row containers, query processors,
and transaction coordinators, which enable uniform
transactional access to diverse information sources.
Typically, OLE DB applications are written as DLLs, but
its COM implementation overcomes the disadvantages of DLLs
(such as naming and version problems) by using componentized
code. In OLE DB, you call interfaces or access other
components using their globally unique identifiers (GUIDs).
Finally, COM keeps track of component usage by using
reference counting. When you call a method on an interface,
the reference count is incremented; when the method returns,
the reference count is decremented. When the count equals
zero, the component to which the method belongs is released.
OLE DB Consumers and Providers
The OLE DB architecture uses the model of consumers and providers. A
consumer makes requests for data. A provider responds to these
requests by placing data in a tabular format and returning it to the
consumer. Any call that the consumer can make must be implemented in
Technically defined, a consumer is any system or application code
(not necessarily an OLE DB component) that accesses data through OLE
DB interfaces. The interfaces are implemented in a provider. Thus, a
provider is any software component that implements OLE DB interfaces
to encapsulate access to data and expose it to other objects (that
In terms of roles, a consumer calls methods on OLE
DB interfaces; an OLE DB provider implements the needed OLE DB
OLE DB avoids the terms client and server because these roles do
not always make sense, especially in an n-tier situation. Because a
consumer could be a component on a tier that serves another
component, to call it a client component would be confusing. Also, a
provider sometimes acts more like a database driver than a server.
OLE DB Object Model
The OLE DB object model comprises the following objects or
components. The first four objects or components listed (data
sources, sessions, commands, and rowsets) allow you to connect to a
data source and view it. The rest, starting with accessors, relate
to working with the data when it is displayed.
Data source objects allow you to connect to a data source
such as a file or DBMS. A data source object creates and
manages the connection and contains permissions and
authentications information (such as login name and
password). A data source object can create one or more
A session manages a particular interaction with the data
source to query and retrieve data. Each session is a single
transaction. A transaction is an indivisible work unit
defined by the ACID test. For a definition of ACID, see
Sessions perform important tasks such as opening rowsets
and returning the data source object that created it.
Sessions can also return metadata, or information about the
data source itself (such as table information).
A session can create one or more commands.
Commands execute a text command such as a SQL statement.
If the text command specifies a rowset, such as a SQL
SELECT statement, the command creates the rowset.
A command is simply a container for a text command, which
is a string (such as a SQL statement) passed from a consumer
to a data source object for execution by the provider's
underlying data store. Typically, the text command is a SQL
SELECT statement (in which case, because SQL
SELECT specifies a rowset, the command automatically
creates a rowset).
Rowsets expose data in tabular format. An index is a
special case of a rowset. You can create rowsets from the
session or the command.
Schemas contain metadata (structural information) about
a database. Schema rowsets are rowsets that contain
schema information. Some OLE DB providers for DBMS
support schema rowset objects. For more information
about schema rowsets, see
Obtaining Metadata with Schema Rowsets and
Schema Rowset Classes and Typedef Classes.
A view object defines a subset of the rows and columns
from a rowset. It contains no data of its own. View
objects cannot combine data from multiple rowsets.
Only OLE DB uses the concept of accessors. An accessor
describes how data is stored in a consumer. It contains a
set of bindings (called a column map) between rowset fields
(columns) and data members that you declare in the consumer.
Transaction objects are used when committing or aborting
nested transactions at other than the lowest level. A
transaction is an indivisible work unit defined by the ACID
test. ACID stands for:
Atomicity: cannot be divided into smaller work
Concurrency: more than one transaction can occur at
Isolation: one transaction has limited knowledge
about changes made by another.
Durability: the transaction makes persistent
Enumerators search for available data sources and other
enumerators. Consumers that are not customized for a
particular data source use enumerators to search for a data
source to use.
A root enumerator, shipped in the Microsoft Data Access
SDK, traverses the registry looking for data sources and
other enumerators. Other enumerators traverse the registry
or search in a provider-specific manner.
Any interface on any OLE DB object can generate errors.
Errors contain additional information about an error,
including an optional custom error object. This information
is contained in an HRESULT.
Notifications are used by groups of cooperating consumers
sharing a rowset (where sharing means that the consumers are
assumed to be working within the same transaction).
Notifications enable cooperating consumers sharing a rowset
to be informed about actions on the rowset performed by
OLE DB Templates, Attributes, and Other Implementations
OLE DB Templates
The OLE DB Templates, which are part of ATL (Active
Template Library), make the high-performance OLE DB database
technology easier to use by providing classes that implement
many of the commonly used OLE DB interfaces. Along with this
template library comes wizard support for creating OLE DB
This template library contains two parts:
OLE DB Consumer Templates Used to implement
an OLE DB client (consumer) application.
OLE DB Provider Templates Used to implement
an OLE DB server (provider) application.
To use the OLE DB Templates, you should be familiar with
C++ templates, COM, and the OLE DB interfaces. If you are
not familiar with OLE DB, see
OLE DB Programmer's Reference.
For more information, you can:
Read the topics about the
OLE DB Consumer Templates or
OLE DB Provider Templates.
OLE DB consumer or
OLE DB provider.
See the list of
OLE DB consumer classes or
OLE DB provider classes.
See the list of
OLE DB templates samples.
OLE DB Programmer's Reference (in the Windows SDK).
OLE DB consumer attributes provide a convenient way to
create OLE DB consumers. The OLE DB attributes inject code
based on the
OLE DB consumer templates to create working OLE DB
consumers and providers. If you need to specify
functionality not supported by the attributes, you can use
the OLE DB Templates in conjunction with attributes in your
OLE DB Classes
The MFC library has one class,
COleDBRecordView, that displays database records in
controls. The view is a form view directly connected to a
CRowset object and displays the fields of the CRowset
object in the dialog template's controls. It also supplies a
default implementation for moving to the first, next,
previous, or last record and an interface for updating the
record currently on view. For more information, see
DB SDK Interfaces
In the cases where the OLE DB Templates do not support
OLE DB functionality, you need to use the OLE DB interfaces
themselves. For more information, see
OLE DB Programmer's Reference in the Windows SDK.
OLE DB Architectural Design Issues
You should consider the following issues before starting your OLE DB
What programming implementation will you use to write
your OLE DB application?
Microsoft offers several libraries to accomplish this: an
OLE DB Template library, OLE DB attributes, and the raw OLE DB
interfaces in the OLE DB SDK. In addition, there are wizards
that help you write your program. These implementations are
OLE DB Templates, Attributes, and Other Implementations.
Do you need to write your own provider?
Most developers do not need to write their own provider.
Microsoft provides several providers. Whenever you create a data
connection (for example, when you add a consumer to your project
using the ATL OLE DB Consumer Wizard), the Data
Link Properties dialog box lists all the available
providers registered on your system. If one of these providers
is appropriate for your own data store and data access
application, the easiest thing to do is use one of these.
However, if your data store does not fit one of these
categories, you have to create your own provider. For
information about creating providers, see
OLE DB Provider Templates.
What level of support do you need for your consumer?
Some consumers can be very basic; while others can be very
complex. The functionality of OLE DB objects is specified by
properties. When you use the ATL OLE DB Consumer Wizard to
create a consumer or the Database Provider Wizard to create a
provider, it sets the appropriate object properties for you to
give you a standard set of functionalities. However, if the
wizard-generated consumer or provider classes do not support
everything you need them to do, you need to refer to the
interfaces for those classes in the
OLE DB Templates Library. These interfaces wrap the raw OLE
DB interfaces, providing extra implementation to make using them
easier for you.
For example, if you want to update data in a
rowset, but forgot to specify this when you created the consumer
with the wizard, you can specify the functionality after the
fact by setting the DBPROP_IRowsetChange and
DBPROP_UPDATABILITY properties on the command object. Then,
when the rowset is created, it has the IRowsetChange
Do you have legacy code using another data access
technology (ADO, ODBC, or DAO)?
Given the possible combinations of technologies (such as
using ADO components with OLE DB components and migrating ODBC
code to OLE DB), covering all situations is beyond the scope of
the Visual C++ documentation. However, many articles covering
various scenarios are available on the following Microsoft Web