OLE DB（OLEDB）是微软的战略性的通向不同的数据源的低级应用程序接口。OLE DB不仅包括微软资助的标准数据接口开放数据库连通性（ODBC）的结构化问题语言（SQL）能力，还具有面向其他非SQL数据类型的通路。 作为微软的组件对象模型（COM）的一种设计，OLE DB是一组读写数据的方法（在过去可能被称为渠道）。OLD DB中的对象主要包括数据源对象、阶段对象、命令对象和行组对象。使用OLE DB的应用程序会用到如下的请求序列： 初始化OLE 连接到数据源 发出命令 处理结果 释放数据源对象并停止初始化OLE
OLE DB标准中定义的新概念----OLE DB将传统的数据库系统划分为多个逻辑组件，这些组件之间相对独立又相互通信。这种组件模型中的各个部分被冠以不同的名称：数据提供者（Data Provider）。 提供数据存储的软件组件，小到普通的文本文件、大到主机上的复杂数据库，或者电子邮件存储，都是数据提供者的例子。有的文档把这些软件组件的开发商也称为数据提供者。
我们要开启如Access 数据库中的数据，必须用ADO.NET 透过OLE DB 来开启。ADO.NET 利用OLE DB 来取得数据，这是因为OLE DB 了解如何和许多种数据源作沟通，所以对OLE DB有相当程度的了解是很重要的。OLE DB 为一种开放式的标准，并且设计成COM（Component
Object Model，一种对象的格式。凡是依照COM 的规格所制作出来的组件，皆可以提供功能让其它程序或组件所使用。）组件。OLE DB 最主要是由三个部分组合而成：
Data Providers 数据提供者
凡是透过OLE DB 将数据提供出来的，就是数据提供者。例如SQL Server 数据库中的数据表，或是附文件名为mdb 的Access 数据库档案等，都是Data Provider。
Data Consumers 数据使用者
凡是使用OLE DB 提供数据的程序或组件，都是OLE DB 的数据使用者。换句话说，凡是使用ADO 的应用程序或网页都是OLE DB 的数据使用者。
Service Components 服务组件
数据服务组件可以执行数据提供者以及数据使用者之间数据传递的工作，数据使用者要向数据提供者要求数据时，是透过OLE DB 服务组件的查询处理器执行查询的工作，而查询到的结果则由指针引擎来管理。
OLE DB 是 Microsoft 的数据访问模型。它使用组件对象模型 (COM) 接口，与 ODBC 不同的是，OLE DB 假定数据源使用的不是 SQL 查询处理器。
Adaptive Server Anywhere 包括一个名为 ASAProv 的 OLE DB 提供程序。该提供程序可用于当前的 Windows 和 Windows CE 平台。
您还可以结合使用 [用于 ODBC 的 Microsoft OLE DB 提供程序](MSDASQL) 和 Adaptive Server Anywhere ODBC 驱动程序来访问 Adaptive Server Anywhere。
使用 Adaptive Server Anywhere OLE DB 提供程序具有以下几个优点：
·某些功能（如通过游标更新）不能通过 OLE DB/ODBC Bridge 来使用。
·如果您使用 Adaptive Server Anywhere OLE DB 提供程序，则在部署过程中无需 ODBC。
·MSDASQL 允许 OLE DB 客户端用于任何 ODBC 驱动程序，但不保证您可以使用每个 ODBC 驱动程序的全部功能。而使用 Adaptive Server Anywhere 提供程序，您可以从 OLE DB 编程环境完全访问 Adaptive Server Anywhere 的全部功能。
一、OLE DB 结构设计问题
开始编写 OLE DB 应用程序之前应考虑以下问题：
使用何种编程实现来编写 OLE DB 应用程序？
Microsoft 提供多种库来解决该问题：OLE DB 模板库、OLE DB 属性以及 OLE DB SDK 中的原始 OLE DB 接口。另外，Microsoft 还提供帮助您编写程序的向导。有关这些实现的更详细的信息，请参见 OLE DB 模板、属性和其他实现。
是否需要编写自己的提供程序？
大多数开发人员无需这样。Microsoft 提供多种提供程序。无论用户何时创建一个数据连接，例如，当使用 ATL OLE DB 使用者向导向项目中添加使用者时，“数据链接属性”对话框都将列出系统中所有被注册的可用提供程序。如果其中一个提供程序适合于用户自己的数据存储和数据访问应用程序，最简单的办法就是使用该提供程序。但是，如果用户的数据存储不适合所提供的类别，则必须创建自己的提供程序。有关创建提供程序的信息，请参见 OLE DB 提供程序模板及其子主题。
需要为自己的使用者提供何种级别的支持？
一些使用者可能非常简单，另一些可能非常复杂。OLE DB 对象的功能由属性指定。使用 ATL OLE DB 使用者向导创建使用者或者使用数据库提供程序向导创建提供程序时，向导将为用户设置合适的对象属性来提供一组标准功能。但是，如果向导生成的使用者类或提供程序类并不具有您需要的所有支持功能，那么您需要查阅这些类在 OLE DB 模板库中的接口。这些接口包装原始 OLE DB 接口，提供附加实现以使其使用起来更加简单。
例如，如果您希望更新行集合中的数据，但在使用向导创建使用者时却忘记指定该功能，则可以在创建使用者之后通过对命令对象设置 DBPROP_IRowsetChange 和 DBPROP_UPDATABILITY 属性来指定该功能。这样，当行集合创建之后，它将具有 IRowsetChange 接口。
您是否有使用其他数据访问技术（ADO、ODBC 或 DAO）的旧版代码？
由于可能有各样各样的技术组合（例如 ADO 组件和 OLE DB 组件一起使用、将 ODBC 代码迁移至 OLE DB 等等），所以 Visual C++ 文档不能涵盖所有的情形。
二、实战应用——使用OLE DB
1 概述
OLE DB的存在为用户提供了一种统一的方法来访问所有不同种类的数据源。OLE DB可以在不同的数据源中进行转换。利用OLE DB，客户端的开发人员在进行数据访问时只需把精力集中在很少的一些细节上，而不必弄懂大量不同数据库的访问协议。
OLE DB是一套通过COM接口访问数据的ActiveX接口。这个OLE DB接口相当通用，足以提供一种访问数据的统一手段，而不管存储数据所使用的方法如何。同时，OLE DB还允许开发人员继续利用基础数据库技术的优点，而不必为了利用这些优点而把数据移出来。
2 使用ATL使用OLE DB数据使用程序
由于直接使用OLE DB的对象和接口设计数据库应用程序需要书写大量的代码。为了简化程序设计，Visual C++提供了ATL模板用于设计OLE DB数据应用程序和数据提供程序。
利用ATL模板可以很容易地将OLE DB与MFC结合起来，使数据库的参数查询等复杂的编程得到简化。MFC提供的数据库类使OLE DB的编程更具有面向对象的特性。Viual C++所提供用于OLE DB的ATL模板可分为数据提供程序的模板和数据使用程序的模板。
使用ATL模板创建数据应用程序一般有以下几步骤：
创建应用框架
加入ATL产生的模板类
在应用中使用产生的数据访问对象
不用ATL使用OLE DB数据使用程序
利用ATL模板产生数据使用程序较为简单，但适用性不广，不能动态适应数据库的变化。下面我们介绍直接使用MFC OLE DB类来生成数据使用程序。
模板的使用
OLE DB数据使用者模板是由一些模板组成的，包括如下一些模板，下面对一些常用类作一些介绍。
会话类
CDataSource类
CDataSource类与OLE DB的数据源对象相对应。这个类代表了OLE DB数据提供程序和数据源之间的连接。只有当数据源的连接被建立之后，才能产生会话对象，可以调用Open来打开数据源的连接。
CSession类
CSession所创建的对象代表了一个单独的数据库访问的会话。一个用CDataSource类产生的数据源对象可以创建一个或者多个会话，要在数据源对象上产生一个会话对象，需要调用函数Open()来打开。同时，会话对象还可用于创建事务操作。
CEnumeratorAccessor类
CEnumeratorAccessor类是用来访问枚举器查询后所产生的行集中可用数据提供程序的信息的访问器，可提供当前可用的数据提供程序和可见的访问器。
访问器类
CAcessor类
CAccessor类代表与访问器的类型。当用户知道数据库的类型和结构时，可以使用此类。它支持对一个行集采用多个访问器，并且，存放数据的缓冲区是由用户分配的。
CDynamicAccessor类
CDynamicAccessor类用来在程序运行时动态的创建访问器。当系统运行时，可以动态地从行集中获得列的信息，可根据此信息动态地创建访问器。
CManualAccessor类
CManualAccessor类中以在程序运行时将列与变量绑定或者是将参数与变量捆定。
行集类
CRowSet类
CRowSet类封装了行集对象和相应的接口，并且提供了一些方法用于查询、设置数据等。可以用Move（）等函数进行记录移动，用GetData()函数读取数据，用Insert()、Delete()、SetData()来更新数据。
CBulkRowset类
CBulkRowset类用于在一次调用中取回多个行句柄或者对多个行进行操作。
CArrayRowset类
CArrayRowset类提供用数组下标进行数据访问。
命令类
CTable类
CTable类用于对数据库的简单访问，用数据源的名称得到行集，从而得到数据。
CCommand类
CCommand类用于支持命令的数据源。可以用Open()函数来执行SQL命令，也可以Prepare（）函数先对命令进行准备，对于支持命令的数据源，可以提高程序的灵活性和健壮性。
在stdafx.h头文件里，加入如下代码。
#include
extern CComModule _Module;
#include
#include
#include // if you are using schema templates
在stdafx.cpp文件里，加入如下代码。
#include
CComModule _Module;
决定使用何种类型的存取程序和行集。
获取数据
在打开数据源，会话，行集对象后就可以获取数据了。所获取的数据类型取决于所用的存取程序，可能需要绑定列。按以下步骤。
用正确的命令打开行集对象。
如果使用CManualAccessor，在使用之前与相应列进行绑定。要绑定列，可以用函数GetColumnInfo,如下所示：
// Get the column information
ULONG ulColumns = 0;
DBCOLUMNINFO* pColumnInfo = NULL;
LPOLESTR pStrings = NULL;
if (rs.GetColumnInfo(&ulColumns, &pColumnInfo, &pStrings) != S_OK)
AfxThrowOLEDBException(rs.m_pRowset, IID_IColumnsInfo);
struct MYBIND* pBind = new MYBIND[ulColumns];
rs.CreateAccessor(ulColumns, &pBind[0], sizeof(MYBIND)*ulColumns);
for (ULONG l=0; l
rs.AddBindEntry(l+1, DBTYPE_STR, sizeof(TCHAR)*40, &pBind[l].szValue, NULL, &pBind[l].dwStatus);
rs.Bind();
用while循环来取数据。在循环中，调用MoveNext来测试光标的返回值是否为S_OK，如下所示：
while (rs.MoveNext() == S_OK)
{
// Add code to fetch data here
// If you are not using an auto accessor, call rs.GetData()
}
在while循环内，可以通过不同的存取程序获取数据。
如果使用的是CAccessor类，可以通过使用它们的数据成员进行直接访问。如下所示：
如果使用的是CDynamicAccessor 或CDynamicParameterAccessor 类，可以通过GetValue或GetColumn函数来获取数据。可以用GetType来获取所用数据类型。如下所示：
while (rs.MoveNext() == S_OK)
{
// Use the dynamic accessor functions to retrieve your
// data
ULONG ulColumns = rs.GetColumnCount();
for (ULONG i=0; i
{
rs.GetValue(i);
}
}
如果使用的是CManualAccessor,可以指定自己的数据成员，绑定它们。就可以直接存取。如下所示：
while (rs.MoveNext() == S_OK)
{
// Use the data members you specified in the calls to
// AddBindEntry.
wsprintf("%s", szFoo);
}
决定行集的数据类型
在运行时决定数据类型，要用动态或手工的存取程序。如果用的是手工存取程序，可以用GetColumnInfo函数得到行集的列信息。从这里可以得到数据类型。
3 总结
由于现在有多种数据源，，想要对这些数据进行访问管理的唯一途径就是通过一些同类机制来实现，如OLE DB。高级OLE DB结构分成两部分：客户和提供者。客户使用由提供者生成的数据。
就像其它基于COM的多数结构一样，OLE DB的开发人员需要实现很多的接口，其中大部分是模板文件。
当生成一个客户对象时，可以通过ATL对象向导指向一个数据源而创建一个简单的客户。ATL对象向导将会检查数据源并创建数据库的客户端代理。从那里，可以通过OLE DB客户模板使用标准的浏览函数。
当生成一个提供者时，向导提供了一个很好的开端，它们仅仅是生成了一个简单的提供者来列举某一目录下的文件。然后，提供者模板包含了OLE DB支持的完全补充内容。在这种支持下，用户可以创建OLE DB提供者，来实现行集定位策略、数据的读写以及建立书签。（来源Builder.com.cn）
OLEDB? 这是什么什么玩艺儿? 也许你们中的许多人以前没有听说过. 要回答这个问题,我们先得回顾一下数据库连接的历史. 是英文(object linking and embedding database)的缩写;
早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
ODBC兼容的数据库包括Access, MS-SQL Server, Oracle, Informix等.
但ODBC并不是完美无缺的,它仍然含有大量的低级的调用,开发ODBC应用程序仍较困难. 开发者不得不将大量的精力花在底层的数据库通信中,而不能专注于他们所要处理的数据. 后来微软提出了一个解决方案: DAO(Data Access Objects). DAO的代码看起来象这样:
objItem.AddNew
objItem.Name = Chair
objItem.Price = 10
objItem.Update
你也许看过DAO的代码. 后来DAO演变为RDO(Remote Data Objects, 为分布式数据库体系设计), 再后来是ADO. 尽管它们都有各自的不足之处. 根据微软的说法,ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象. DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
OLEDB位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的应用程序. 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升. 那我们该如何直接连接到OLEDB呢?
要想直接连到OLEDB层,你必须改变你的connection对象连接字符串. 先用老办法创建一个connectiong对象:
Dim objConn
Set objConn = Server.CreateObject(ADODB.Connection)
接下去,我们不用常规的类似DSN=pubs or DRIVER={MS SQL-
Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine的连接字符串,而采用下面的连接字符串:
objConn.ConnectionString = Provider=ProviderName; Data
Source=DatabaseSource; Initial Catalog=DatabaseName; User ID=UserID;
Password=Password
对于SQL:
ProviderName = SQLOLEDB
Data Source = Server Name
Initial Catalog = Database Name
对于Access:
ProviderName = Microsoft.Jet.OLEDB.3.51
Data Source = Full path to .MDB file
下面让我们来看两个例子,一个是针对Access的,还有一个是针对SQL的. 如果你的连接SQL的DSN-less连接串是这样的:
DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; User
ID=sa; Password=
让我们来看看Access,如果你的Access的连接字符串是:
DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=c:\inetpub\wwwroot\users.mdb
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=Microsoft.Jet.OLEDB.3.51; Data
Source=c:\inetpub\wwwroot\users.mdb
就是这么简单,挺棒的吧?
这很重要吗?
现在你也许对为什么要学习这种新的数据库连接方法感到有些儿迷惑,为什么不走标准的DSN-less/System DSN路子呢? 让我来告诉你为什么. 据Wrox出的ADO 2.0
Programmer's Reference一书中的测试,用OLEDB连接而不是DSN或DSN-less的连接会得到的性能提升如下:
性能比较
SQL Access
OLEDB DSN OLEDB DSN
Connection Times: 18 82 Connection Times: 62 99
Iterating through 1,000 Records Times: 2900 5400 Iterating through 1,000 Records Times: 100 950