OLEDB和ODBC以及ADO的解释
*******************
历史篇
*******************
史前
那时候每个数据库供应商（其实也没几个）
都有自己的数据库操作API，
每个应用程序只能使用一个固定的数据库
想换数据库？没门！你要全部重新写
后来
X/OPEN和ISO(好像还有IBM)说
这么乱，程序员怎么活啊
于是提出了CLI（Call-Level Interface）
每个数据库的CLI(驱动程序)基本上相同，
程序员总算好过点了，可是要换数据库，
你写的程序需要重新编译（或许还要安装）
再后来
于是ODBC来了，它通过动态装载各个数据库的CLI
把函数调用转换成每个数据库的CLI调用
数据库应用程序总算和数据库供应商每什么关系了
再后来
MS提出了OLE，MS还有了自己的数据库
(Access/SQL Server)
MS是老大，这个问题上当然要有自己的看法
要是还只是提供ODBC，那多没面子
所以提出了 OLE-DB,它通过COM接口调用
OLE-DB也需要每个数据库提供一个CLI
（不过有了新名词，叫作Provider)
MS 给 Access和SqlServer分别写了一个Provider
不过为了照顾使用ODBC的，也提供了一个ODBC的Provider
这样那些只提供ODBC的数据库也可以通过OLE-DB访问
不过这样效率就稍微低了(因为要经过两层么)
所以现在有些数据库会提供自己的Provider
再后来
MS说OLE-DB的接口太复杂了
程序员也就调调QUERY
没必要搞这么复杂吧
于是提出了ADO,ADO 通过在OLE-DB上面封装
简化了使用方法,程序员在操作数据库上总算是解放了
新世纪终于到来了
MS也发明了.NET,为了适应新世纪新潮流
也提出了 ADO.NET
*******************
原理篇：
*******************
ODBC(OpenDataBase Connectivity，开放数据库互连)是微软公司开放服务结构(WOSA，Windows OpenServices Architecture)中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。这些API利用SQL来完成其大部分任务。ODBC本身也提供了对SQL语言的支持，用户可以直接将SQL语句送给ODBC。它本身就是为了是数据库的使用者不必考虑使用的是何种数据库而只需要相同的操作而设计的
ODBC中提供三种DSN(Data Source Name),它们的区别很简单：用户dsn只能用于本用户。系统dsn和文件dsn的区别只在于连接信息的存放位置不同：系统dsn存放在odbc储存区里，而文件dsn则放在一个文本文件中。
OLE-DB(对象链接和嵌入数据库)位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLE-DB之上的"应用程序". 你的ADO调用先被送到OLE-DB,然后再交由ODBC处理. 你可以直接连接到OLE-DB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升.
ADO:其实只是一个应用程序层次的界面，它用 OLE-DB 来与数据库通信。
值得注意的是，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提供者的速度慢一些。