OLE DB 的概念
简单地说，OLE DB 是一种技术标准，目的是提供一种统一的数据访问接口，这里所说的“数据”，除了标准的关系型数据库中的数据之外，还包括邮件数据、Web 上的文本或图形、目录服务（Directory Services），以及主机系统中的IMS 和VSAM 数据。OLE DB 标准的核心内容就是要求以上这些各种各样的数据存储（Data Store）都提供一种相同的访问接口，使得数据的使用者（应用程序）可以使用同样的方法访问各种数据，而不用考虑数据的具体存储地点、格式或类型。
OLE DB 标准的具体实现是一组C++ API 函数，就像ODBC 标准中的ODBC API 一样，不同的是，OLE DB 的API 是符合COM 标准、基于对象的（ODBC API 则是简单的C API）。使用OLE DB API，可以编写能够访问符合OLE DB 标准的任何数据源的应用程序，也可以编写针对某种特定数据存储的查询处理程序（Query Processor）和游标引擎（Cursor Engine），因此OLE DB 标准实际上是规定了数据使用者和提供者之间的一种应用层的协议（Application-Level Protocol）。
即将发布的微软最新数据库产品SQL Server 7.0 的查询处理程序就是使用OLE DB API 编写的，所以在SQL Server 7.0 的Transact-SQL 语法中，可以支持异种数据库的查询，当然，这些异种数据库必须也提供相应的OLE DB 访问接口。
OLE DB 标准中定义的新概念
OLE DB 将传统的数据库系统划分为多个逻辑组件，这些组件之间相对独立又相互通信。这种组件模型中的各个部分被冠以不同的名称：
数据提供者（Data Provider）。提供数据存储的软件组件，小到普通的文本文件、大到主机上的复杂数据库，或者电子邮件存储，都是数据提供者的例子。有的文档把这些软件组件的开发商也称为数据提供者。
数据服务提供者（Data Service Provider）。位于数据提供者之上、从过去的数据库管理系统中分离出来、独立运行的功能组件，例如查询处理器和游标引擎（Cursor Engine），这些组件使得数据提供者提供的数据以表状数据（Tabular Data）的形式向外表示（不管真实的物理数据是如何组织和存储的），并实现数据的查询和修改功能。SQL Server 7.0 的查询处理程序就是这种组件的典型例子。
业务组件（Business Component）。利用数据服务提供者、专门完成某种特定业务信息处理、可以重用的功能组件。分布式数据库应用系统中的中间层（Middle-Tier）就是这种组件的典型例子。
数据消费者（Data Consumer）。任何需要访问数据的系统程序或应用程序，除了典型的数据库应用程序之外，还包括需要访问各种数据源的开发工具或语言。
OLE DB 与ODBC 的关系
由于OLE DB 和ODBC 标准都是为了提供统一的访问数据接口，所以曾经有人疑惑：OLE DB 是不是替代ODBC 的新标准？答案是否定的。实际上，ODBC 标准的对象是基于SQL 的数据源（SQL-Based Data Source），而OLE DB 的对象则是范围更为广泛的任何数据存储。从这个意义上说，符合ODBC 标准的数据源是符合OLE DB 标准的数据存储的子集。符合ODBC 标准的数据源要符合OLE DB 标准，还必须提供相应的OLE DB 服务程序（Service Provider），就像SQL Server 要符合ODBC 标准，必须提供SQL Server ODBC 驱动程序一样。现在，微软自己已经为所有的ODBC 数据源提供了一个统一的OLE DB 服务程序，叫做ODBC OLE DB Provider。
ODBC OLE DB Provider 发布之后，有人又担心：ODBC Provider 是不是在ODBC 之上的新的层次（Layer）？如果是，那么使用OLE DB 访问ODBC 数据源是否将影响性能？答案也是否定的。实际上，ODBC Provider 的作用，是替换ODBC Driver Manager，作为应用程序与ODBC 驱动程序之间的桥梁，理论上不会增加任何开销。
ADO 的概念
我们已经知道，OLE DB 标准的API 是C++ API，只能供C++ 语言调用（这也是OLE DB 没有改名为ActiveX DB 的原因，ActiveX 是与语言无关的组件技术）。为了使得流行的各种编程语言都可以编写符合OLE DB 标准的应用程序，微软在OLE DB API 之上，提供了一种面向对象、与语言无关的（Language-Neutral）应用编程接口，这就是ActiveX Data Objects，简称ADO。
与DAO、RDO 等类似，ADO 实际上是一种对象模型，不过这个对象模型相对简单，示意如下：
在这个对象模型中，Connection 类似于RDO 的rdoConnection 或者DAO 的Database，Command 类似于RDO 的rdoPreparedStatement 或者DAO 的QueryDef。
值得注意的是：与DAO 等模型的层次结构不同，ADO 基本上是一种平板结构：Command 和Recordset 与Connect 之间并没有上下层次关系，这种设计主要是为了适应Internet 应用开发的需要。因为在Internet 上，像在局域网内那样维护一个永久性的连接、然后在连接的基础上执行查询，基本上是不可能的。
ADO 与其他编程接口的比较
网络数据库应用程序的开发可以使用的编程接口包括：DAO、ADO、RDO、ODBC API 和DB-Library 等，应用系统的框架模型示意如下：
除了这些标准的编程接口之外，还有一些应用程序（例如MS Access）也可以作为访问远程数据库的编程工具。这些接口或工具在编程的简便程度和利用远程数据库的功能方面差异很大，如下图所示：
可以看出，使用MS Access（通过DAO/JET），编程非常容易，但是因为把远程网络数据库当成本地Access 数据库对待，很难利用网络数据库的高级特性；而ODBC API 则刚好相反，数据库管理系统的特性几乎可以完全利用，但是编程复杂，效率低。
我们关心的ADO 在编程难易程度方面比DAO 和RDO 都好（主要得益于简单的对象模型），但是在利用数据库的特性方面与RDO 不相上下；至于程序运行效率，ADO 当前的版本是1.5，性能方面与RDO 还有一定的差距，当Visual Studio 6 发布时，ADO 将升级到2.0 版，新版本在功能和性能方面都将与RDO 相当或更强。因此对于应用开发人员来说，ADO 是一种非常有前途的编程接口。
实际上，微软已经公开表示，今后的微软产品在数据访问的接口方面，将统一到OLE DB 和ADO 标准上来。
========================================================================
ODBC(开放数据库互连):是Microsoft引进的一种早期数据库接口技术。它实际上是ADO的前身。早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
OLEDB(对象链接和嵌入数据库)位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的"应用程序". 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升.
用odbc连接数据库：
odbc中提供三种dsn,它们的区别很简单：用户dsn只能用于本用户。系统dsn和文件dsn的区别只在于连接信息的存放位置不同：系统dsn存放在odbc储存区里，而文件dsn则放在一个文本文件中。
它们的创建方法就不说了。
在asp中使用它们时，写法如下：
A.sql server:
用系统dsn: connstr="DSN=dsnname; UID=xx; PWD=xxx;DATABASE=dbname"
用文件dsn: connstr="FILEDSN=xx;UID=xx; PWD=xxx;DATABASE=dbname"
还可以用连接字符串（从而不用再建立dsn):
connstr="DRIVER={sql server};SERVER=servername;UID=xx;PWD=xxx"
B.access:
用系统dsn: connstr="DSN=dsnname"
(或者为：connstr="DSN=dsnname;UID=xx;PWD=xxx")
用文件dsn: connstr="FILEDSN=xx"
还可以用连接字符串（从而不用再建立dsn):
connstr="DRIVER={Microsoft Access Driver};DBQ=d:abcabc.mdb"
用oledb连接数据库：
A.sql server:
connstr="PROVIDER=SQLOLEDB;
DATA SOURCE=servername;UID=xx;PWD=xxx;DATABASE=dbname"
B.access:
connstr="PROVICER=MICROSOFT.JET.OLEDB.4.0;
DATA SOURCE=c:abcabc.mdb"
值得注意的是，OLE DB对ODBC的兼容性，允许OLE DB访问现有的ODBC数据源。其优点很明显，由于ODBC相对OLE DB来说使用得更为普遍，因此可以获得的ODBC驱动程序相应地要比OLE DB的要多。这样不一定要得到OLE DB的驱动程序，就可以立即访问原有的数据系统。
提供者位于OLE DB层，而驱动程序位于ODBC层。如果想使用一个ODBC数据源，需要使用针对ODBC的OLE DB提供者，它会接着使用相应的ODBC驱动程序。如果不需要使用ODBC数据源，那么可以使用相应的OLE DB提供者，这些通常称为本地提供者（native provider）。
可以清楚地看出使用ODBC提供者意味着需要一个额外的层。因此，当访问相同的数据时，针对ODBC的OLE DB提供者可能会比本地的OLE DB提供者的速度慢一些。
OLE DB 标准的具体实现是一组C++ API 函数，就像ODBC 标准中的ODBC API 一样，不同的是，OLE DB 的API 是符合COM 标准、基于对象的（ODBC API 则是简单的C API）。使用OLE DB API，可以编写能够访问符合OLE DB 标准的任何数据源的应用程序，也可以编写针对某种特定数据存储的查询处理程序（Query Processor）和游标引擎（Cursor Engine），因此OLE DB 标准实际上是规定了数据使用者和提供者之间的一种应用层的协议（Application-Level Protocol）。
即将发布的微软最新数据库产品SQL Server 7.0 的查询处理程序就是使用OLE DB API 编写的，所以在SQL Server 7.0 的Transact-SQL 语法中，可以支持异种数据库的查询，当然，这些异种数据库必须也提供相应的OLE DB 访问接口。
OLE DB 标准中定义的新概念
OLE DB 将传统的数据库系统划分为多个逻辑组件，这些组件之间相对独立又相互通信。这种组件模型中的各个部分被冠以不同的名称：
数据提供者（Data Provider）。提供数据存储的软件组件，小到普通的文本文件、大到主机上的复杂数据库，或者电子邮件存储，都是数据提供者的例子。有的文档把这些软件组件的开发商也称为数据提供者。
数据服务提供者（Data Service Provider）。位于数据提供者之上、从过去的数据库管理系统中分离出来、独立运行的功能组件，例如查询处理器和游标引擎（Cursor Engine），这些组件使得数据提供者提供的数据以表状数据（Tabular Data）的形式向外表示（不管真实的物理数据是如何组织和存储的），并实现数据的查询和修改功能。SQL Server 7.0 的查询处理程序就是这种组件的典型例子。
业务组件（Business Component）。利用数据服务提供者、专门完成某种特定业务信息处理、可以重用的功能组件。分布式数据库应用系统中的中间层（Middle-Tier）就是这种组件的典型例子。
数据消费者（Data Consumer）。任何需要访问数据的系统程序或应用程序，除了典型的数据库应用程序之外，还包括需要访问各种数据源的开发工具或语言。
OLE DB 与ODBC 的关系
由于OLE DB 和ODBC 标准都是为了提供统一的访问数据接口，所以曾经有人疑惑：OLE DB 是不是替代ODBC 的新标准？答案是否定的。实际上，ODBC 标准的对象是基于SQL 的数据源（SQL-Based Data Source），而OLE DB 的对象则是范围更为广泛的任何数据存储。从这个意义上说，符合ODBC 标准的数据源是符合OLE DB 标准的数据存储的子集。符合ODBC 标准的数据源要符合OLE DB 标准，还必须提供相应的OLE DB 服务程序（Service Provider），就像SQL Server 要符合ODBC 标准，必须提供SQL Server ODBC 驱动程序一样。现在，微软自己已经为所有的ODBC 数据源提供了一个统一的OLE DB 服务程序，叫做ODBC OLE DB Provider。
ODBC OLE DB Provider 发布之后，有人又担心：ODBC Provider 是不是在ODBC 之上的新的层次（Layer）？如果是，那么使用OLE DB 访问ODBC 数据源是否将影响性能？答案也是否定的。实际上，ODBC Provider 的作用，是替换ODBC Driver Manager，作为应用程序与ODBC 驱动程序之间的桥梁，理论上不会增加任何开销。
ADO 的概念
我们已经知道，OLE DB 标准的API 是C++ API，只能供C++ 语言调用（这也是OLE DB 没有改名为ActiveX DB 的原因，ActiveX 是与语言无关的组件技术）。为了使得流行的各种编程语言都可以编写符合OLE DB 标准的应用程序，微软在OLE DB API 之上，提供了一种面向对象、与语言无关的（Language-Neutral）应用编程接口，这就是ActiveX Data Objects，简称ADO。
与DAO、RDO 等类似，ADO 实际上是一种对象模型，不过这个对象模型相对简单，示意如下：
在这个对象模型中，Connection 类似于RDO 的rdoConnection 或者DAO 的Database，Command 类似于RDO 的rdoPreparedStatement 或者DAO 的QueryDef。
值得注意的是：与DAO 等模型的层次结构不同，ADO 基本上是一种平板结构：Command 和Recordset 与Connect 之间并没有上下层次关系，这种设计主要是为了适应Internet 应用开发的需要。因为在Internet 上，像在局域网内那样维护一个永久性的连接、然后在连接的基础上执行查询，基本上是不可能的。
ADO 与其他编程接口的比较
网络数据库应用程序的开发可以使用的编程接口包括：DAO、ADO、RDO、ODBC API 和DB-Library 等，应用系统的框架模型示意如下：
除了这些标准的编程接口之外，还有一些应用程序（例如MS Access）也可以作为访问远程数据库的编程工具。这些接口或工具在编程的简便程度和利用远程数据库的功能方面差异很大，如下图所示：
可以看出，使用MS Access（通过DAO/JET），编程非常容易，但是因为把远程网络数据库当成本地Access 数据库对待，很难利用网络数据库的高级特性；而ODBC API 则刚好相反，数据库管理系统的特性几乎可以完全利用，但是编程复杂，效率低。
我们关心的ADO 在编程难易程度方面比DAO 和RDO 都好（主要得益于简单的对象模型），但是在利用数据库的特性方面与RDO 不相上下；至于程序运行效率，ADO 当前的版本是1.5，性能方面与RDO 还有一定的差距，当Visual Studio 6 发布时，ADO 将升级到2.0 版，新版本在功能和性能方面都将与RDO 相当或更强。因此对于应用开发人员来说，ADO 是一种非常有前途的编程接口。
实际上，微软已经公开表示，今后的微软产品在数据访问的接口方面，将统一到OLE DB 和ADO 标准上来。
========================================================================
ODBC(开放数据库互连):是Microsoft引进的一种早期数据库接口技术。它实际上是ADO的前身。早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
OLEDB(对象链接和嵌入数据库)位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的"应用程序". 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升.
用odbc连接数据库：
odbc中提供三种dsn,它们的区别很简单：用户dsn只能用于本用户。系统dsn和文件dsn的区别只在于连接信息的存放位置不同：系统dsn存放在odbc储存区里，而文件dsn则放在一个文本文件中。
它们的创建方法就不说了。
在asp中使用它们时，写法如下：
A.sql server:
用系统dsn: connstr="DSN=dsnname; UID=xx; PWD=xxx;DATABASE=dbname"
用文件dsn: connstr="FILEDSN=xx;UID=xx; PWD=xxx;DATABASE=dbname"
还可以用连接字符串（从而不用再建立dsn):
connstr="DRIVER={sql server};SERVER=servername;UID=xx;PWD=xxx"
B.access:
用系统dsn: connstr="DSN=dsnname"
(或者为：connstr="DSN=dsnname;UID=xx;PWD=xxx")
用文件dsn: connstr="FILEDSN=xx"
还可以用连接字符串（从而不用再建立dsn):
connstr="DRIVER={Microsoft Access Driver};DBQ=d:abcabc.mdb"
用oledb连接数据库：
A.sql server:
connstr="PROVIDER=SQLOLEDB;
DATA SOURCE=servername;UID=xx;PWD=xxx;DATABASE=dbname"
B.access:
connstr="PROVICER=MICROSOFT.JET.OLEDB.4.0;
DATA SOURCE=c:abcabc.mdb"
值得注意的是，OLE DB对ODBC的兼容性，允许OLE DB访问现有的ODBC数据源。其优点很明显，由于ODBC相对OLE DB来说使用得更为普遍，因此可以获得的ODBC驱动程序相应地要比OLE DB的要多。这样不一定要得到OLE DB的驱动程序，就可以立即访问原有的数据系统。
提供者位于OLE DB层，而驱动程序位于ODBC层。如果想使用一个ODBC数据源，需要使用针对ODBC的OLE DB提供者，它会接着使用相应的ODBC驱动程序。如果不需要使用ODBC数据源，那么可以使用相应的OLE DB提供者，这些通常称为本地提供者（native provider）。
可以清楚地看出使用ODBC提供者意味着需要一个额外的层。因此，当访问相同的数据时，针对ODBC的OLE DB提供者可能会比本地的OLE DB提供者的速度慢一些。