关于数据源连接提供者和数据源连接
类别: ASP教程 
我是初学ASP的，深入一点后，让我困惑不已的就是数据库的连接，我经常看到对于同一个Microsoft Access数据库使用两种方式，或是三种，甚至四种方式的连接，最让我不能理解的是这两种：
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=databasename;"
%>
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DBQ=databasename; Driver=Microsoft Access Driver (*.MDB);"
%>
为什么是这样的呢？带着这样的问题，我开始系统地来看数据源连接的问题。让我有所顿悟的是xmxoxo曾给我们的一个ADO结构图，还有便是我使用了OLE DB数据连接文件（.udl）文件来创建数据源连接。
ADO的结构图：
┏━━━━━━━━━━━━━┓
┃ A S P应用程序 ┃
┗━━━━━━┳━━━━━━┛
┃
┃
┏━━━━━━┻━━━━━━┓
┃ A D O对象 ┃
┗━━━━━━┳━━━━━━┛
┃
┃
┏━━━━━━┻━━━━━━━━┓
┃ OLE DB接口 ┃
┣━━━━━━━┳━━━━━━━┫
┃Microsoft OLE┃ 其它的 ┃
┃ DB Provider ┃ OLE DB Data ┃
┃ for ODBC ┃ Provider ┃
┗━━┳━━━━┻━━━┳━━━┛
┃ ┃
┃ ┃
┏━━┻━━━━━━┓ ┃
┃ 各种ODBCDriver ┃ ┃
┗━━┳━━━━━━┛ ┃
┃ ┃
┃ ┃
┏━━┻━━━━━━━━┻━━┓
┃ 各种数据库源 ┃
┗━━━━━━━━━━━━━━┛
下面我就谈谈我对数据源连接的总的看法。
首先要肯定的是这个ADO结构图，ADO的模式是必须通过OLE DB接口来访问所有的数据源，也就是说，ADO期望所有的数据源都提供面向OLE DB接口的驱动。
可众所周知，当前我们使用的所有的数据库管理系统--DBMS实际上都可以通过 ODBC进行互访，这是因为ODBC提供了各类数据源的驱动。 然而ADO访问数据源的统一界面却是个OLE DB接口，这样一来，尽管有越来越多数据库厂商开始也提供OLE DB 接口，比如SQL Server、Oracle以及Microsoft Access（Microsoft Jet 数据库引擎）等等，但仍有一些数据源无法以这种方式提供，仍然需要借助ODBC驱动向OLE DB提供。这样的话，OLE DB便定义了一个嵌入使用ODBC驱动的接口，就象是ODBC驱动也象其他数据库驱动的提供者一样插在了OLE DB型号的插座上。给ODBC这个接口的名字（即OLE DB提供者）便是Microsoft OLE DB Provider for ODBC drivers，是ADO默认的提供者。关键字Provider的值为MSDASQL，可以省略不写，因而我们在建立数据源连接时，没看到provider的话，那说明，肯定是ODBC提供的驱动。
怎么样？困惑我很久的两个名词OLE DB和ODBC我总算是看清楚了。
实际上简单地说，这两个东东不能等同起来，因为不是一个范畴。ODBC是乐善好施的恩主，是为各种数据源提供驱动的提供者，而OLE DB根本就是个独裁者，它要所有的数据源都向它屈服，提供符合它标准的驱动。
接下来我们用实践来证明这一点，我们的ODBC的确是受控于OLE DB的。
看书上写的通常是建立数据库通常有“DSN方法及非DSN方法”，这种说法只能是针对ODBC驱动而言。对OLE DB来说只有“UDL方式”及“非UDL方式”，因为回头我们便可以看见“DSN方法及非DSN方法”，只不过是OLE DB下的“非UDL方式”。
我们先来看看ADO建立数据源连接的对象Connection的用法。
从ADO参考上大家可以看到Connection对象有很多属性，我们只谈论它的两个属性，一个是Provider,另一个便是connectionString，这两个关系到我们数据源的最终连接。
下面这段是关于Provider属性，拷贝于ADO参考。
使用 Provider 属性可设置或返回连接提供者的名称。也可以通过 ConnectionString 属性的内容或 Open方法的 ConnectionString 参数设置该属性。但是，调用 Open 方法时在多处指定提供者可能会产生无法预料的后果。
如果没有指定提供者，该属性将默认为 MSDASQL (Microsoft OLE DB Provider for ODBC ）。
同样大家也可以在参考中找到这么一点。使用 ConnectionString 属性，是通过详细连接字符串来指定数据源的。而我们的ADO 支持的ConnectionString 属性只有四个参数，其中有两个还是针对远程数据服务，也就是说对我们来讲，
它支持的只有两个，是哪两个呢？
是Provider= 指定用来连接的提供者名称。 糟糕，这个刚刚不是已经有过吗？没错，和哪个Provider属性做一样的事，那岂不是只有一个！没错，唯一的一个是File Name。而File Name= 指定包含预先设置连接信息的特定提供者的文件名称，其实通常就是后缀为.udl的文件。好象这个File Name对大多数人来讲，也没有用过，惨！那我们平时用的算什么呢？
别急，还有一句话！“任何其他参数将直接传递到提供者而不经过 ADO 处理”。那就是说我们平时常用的连接参数实际上对ADO来讲，就是被它这样给处理掉了。
接下来动手做做，我们以创建一个连接Microsoft Access数据库mydb.mdb的连接为例
使用Microsoft.Jet.OLEDB.4.0提供者
对我来说，我把下面这种连接看成是“UDL方式”
先要创建一个udlfile.udl文件，是利用文件管理器的一个进程“数据连接属性”来创建的。可以这么做，先建一个空的.txt文件，然后改名为.udl就可以启动该进程生成所需的OLEDB数据连接.udl文档了。
在这里，你可以指定OLE DB提供者为Microsoft.Jet.OLEDB.4.0，
再指定数据源是C:InetpubwwwrootaspadodbMYDB.MDB。
这样我们会得到一个具有以下内容的udlfile.udl文件
[oledb]
Provider=Microsoft.Jet.OLEDB.4.0;Data source=C:InetpubwwwrootaspadodbMYDB.MDB;
之后在.asp文件中利用该udl文件来建立数据源的连接
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Open "File Name=c:udludlfile.udl"
%>
什么是“非UDL方式”呢？
就是指不建立UDL文件，而是直接在程序中指定，即：
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=C:InetpubwwwrootaspadodbMYDB.MDB;"
%>
大家看出来了，我们平时这种指定的用法其实用的就是.udl文件中生成的连接字符串我们知道Access数据库除了用上面这种驱动，还可以使用ODBC提供的驱动，
这样的话，我们仍用“UDL方式”和“非UDL方式”两种方式来操作一下。另外，由于涉及ODBC驱动，所以会存在DSN及非DSN的选择，我们选择“系统DSN方式”，假设名字叫mydsn好了。
UDL方式
用和上面一样的方法建立一个文件udlodbc.udl,选择数据提供者为Microsoft OLE DB Provider for ODBC drivers ，如果你事先已经建好了系统DSN的话，就可以直接在数据源中选中系统DSN的名字mydsn了，这样做似乎会有些问题。最好还是选择使用“生成连接字符串”，点击“编译”，便弹出数据源选择窗口，我们选用机器数据源标签，从里面可以选择我们已经建立了的系统DSN名字mydsn，然后确定。其实，你也可以重新创建一个新的系统DSN，这时你会看到，创建新的DSN的界面，就是ODBC的界面。（至于如何创建系统DSN我就不细说了）
这样我们的udlodbc.udl就建立了，用记事本打开看看，内容大致如下：
[oledb]
Provider=MSDASQL.1;
Extended properties= "DSN=mydsn;
DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;"
接下来和上面是一样的，在.asp程序中使用该.udl文件
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Open "File Name=c:udludlodbc.udl"
%>
那什么是这种情况下“非UDL方式”呢？当然也是把连接字符串写在程序中了
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=MSDASQL.1;
Extended properties=""DSN=mydsn;
DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;"""
%>
我们再根据ADO的默认情况，省略掉可以不写的部分，便成了以下的样子：
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DSN=mydsn;"
%>
这就是我们常说的系统DSN方法。
大家可以推导出文件DSN方法，以及非DSN方法都是如此
文件DSN方法，假设文件名为odbc.dsn
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "FileDSN=c:dsnodbc.dsn;"
%>
非DSN方法
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;Driver={Microsoft Access Driver (*.mdb)};"
%>
好了，这些观点纯属个人见解！由于本人水平有限，望大家多多指教！
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=databasename;"
%>
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DBQ=databasename; Driver=Microsoft Access Driver (*.MDB);"
%>
为什么是这样的呢？带着这样的问题，我开始系统地来看数据源连接的问题。让我有所顿悟的是xmxoxo曾给我们的一个ADO结构图，还有便是我使用了OLE DB数据连接文件（.udl）文件来创建数据源连接。
ADO的结构图：
┏━━━━━━━━━━━━━┓
┃ A S P应用程序 ┃
┗━━━━━━┳━━━━━━┛
┃
┃
┏━━━━━━┻━━━━━━┓
┃ A D O对象 ┃
┗━━━━━━┳━━━━━━┛
┃
┃
┏━━━━━━┻━━━━━━━━┓
┃ OLE DB接口 ┃
┣━━━━━━━┳━━━━━━━┫
┃Microsoft OLE┃ 其它的 ┃
┃ DB Provider ┃ OLE DB Data ┃
┃ for ODBC ┃ Provider ┃
┗━━┳━━━━┻━━━┳━━━┛
┃ ┃
┃ ┃
┏━━┻━━━━━━┓ ┃
┃ 各种ODBCDriver ┃ ┃
┗━━┳━━━━━━┛ ┃
┃ ┃
┃ ┃
┏━━┻━━━━━━━━┻━━┓
┃ 各种数据库源 ┃
┗━━━━━━━━━━━━━━┛
下面我就谈谈我对数据源连接的总的看法。
首先要肯定的是这个ADO结构图，ADO的模式是必须通过OLE DB接口来访问所有的数据源，也就是说，ADO期望所有的数据源都提供面向OLE DB接口的驱动。
可众所周知，当前我们使用的所有的数据库管理系统--DBMS实际上都可以通过 ODBC进行互访，这是因为ODBC提供了各类数据源的驱动。 然而ADO访问数据源的统一界面却是个OLE DB接口，这样一来，尽管有越来越多数据库厂商开始也提供OLE DB 接口，比如SQL Server、Oracle以及Microsoft Access（Microsoft Jet 数据库引擎）等等，但仍有一些数据源无法以这种方式提供，仍然需要借助ODBC驱动向OLE DB提供。这样的话，OLE DB便定义了一个嵌入使用ODBC驱动的接口，就象是ODBC驱动也象其他数据库驱动的提供者一样插在了OLE DB型号的插座上。给ODBC这个接口的名字（即OLE DB提供者）便是Microsoft OLE DB Provider for ODBC drivers，是ADO默认的提供者。关键字Provider的值为MSDASQL，可以省略不写，因而我们在建立数据源连接时，没看到provider的话，那说明，肯定是ODBC提供的驱动。
怎么样？困惑我很久的两个名词OLE DB和ODBC我总算是看清楚了。
实际上简单地说，这两个东东不能等同起来，因为不是一个范畴。ODBC是乐善好施的恩主，是为各种数据源提供驱动的提供者，而OLE DB根本就是个独裁者，它要所有的数据源都向它屈服，提供符合它标准的驱动。
接下来我们用实践来证明这一点，我们的ODBC的确是受控于OLE DB的。
看书上写的通常是建立数据库通常有“DSN方法及非DSN方法”，这种说法只能是针对ODBC驱动而言。对OLE DB来说只有“UDL方式”及“非UDL方式”，因为回头我们便可以看见“DSN方法及非DSN方法”，只不过是OLE DB下的“非UDL方式”。
我们先来看看ADO建立数据源连接的对象Connection的用法。
从ADO参考上大家可以看到Connection对象有很多属性，我们只谈论它的两个属性，一个是Provider,另一个便是connectionString，这两个关系到我们数据源的最终连接。
下面这段是关于Provider属性，拷贝于ADO参考。
使用 Provider 属性可设置或返回连接提供者的名称。也可以通过 ConnectionString 属性的内容或 Open方法的 ConnectionString 参数设置该属性。但是，调用 Open 方法时在多处指定提供者可能会产生无法预料的后果。
如果没有指定提供者，该属性将默认为 MSDASQL (Microsoft OLE DB Provider for ODBC ）。
同样大家也可以在参考中找到这么一点。使用 ConnectionString 属性，是通过详细连接字符串来指定数据源的。而我们的ADO 支持的ConnectionString 属性只有四个参数，其中有两个还是针对远程数据服务，也就是说对我们来讲，
它支持的只有两个，是哪两个呢？
是Provider= 指定用来连接的提供者名称。 糟糕，这个刚刚不是已经有过吗？没错，和哪个Provider属性做一样的事，那岂不是只有一个！没错，唯一的一个是File Name。而File Name= 指定包含预先设置连接信息的特定提供者的文件名称，其实通常就是后缀为.udl的文件。好象这个File Name对大多数人来讲，也没有用过，惨！那我们平时用的算什么呢？
别急，还有一句话！“任何其他参数将直接传递到提供者而不经过 ADO 处理”。那就是说我们平时常用的连接参数实际上对ADO来讲，就是被它这样给处理掉了。
接下来动手做做，我们以创建一个连接Microsoft Access数据库mydb.mdb的连接为例
使用Microsoft.Jet.OLEDB.4.0提供者
对我来说，我把下面这种连接看成是“UDL方式”
先要创建一个udlfile.udl文件，是利用文件管理器的一个进程“数据连接属性”来创建的。可以这么做，先建一个空的.txt文件，然后改名为.udl就可以启动该进程生成所需的OLEDB数据连接.udl文档了。
在这里，你可以指定OLE DB提供者为Microsoft.Jet.OLEDB.4.0，
再指定数据源是C:InetpubwwwrootaspadodbMYDB.MDB。
这样我们会得到一个具有以下内容的udlfile.udl文件
[oledb]
Provider=Microsoft.Jet.OLEDB.4.0;Data source=C:InetpubwwwrootaspadodbMYDB.MDB;
之后在.asp文件中利用该udl文件来建立数据源的连接
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Open "File Name=c:udludlfile.udl"
%>
什么是“非UDL方式”呢？
就是指不建立UDL文件，而是直接在程序中指定，即：
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=C:InetpubwwwrootaspadodbMYDB.MDB;"
%>
大家看出来了，我们平时这种指定的用法其实用的就是.udl文件中生成的连接字符串我们知道Access数据库除了用上面这种驱动，还可以使用ODBC提供的驱动，
这样的话，我们仍用“UDL方式”和“非UDL方式”两种方式来操作一下。另外，由于涉及ODBC驱动，所以会存在DSN及非DSN的选择，我们选择“系统DSN方式”，假设名字叫mydsn好了。
UDL方式
用和上面一样的方法建立一个文件udlodbc.udl,选择数据提供者为Microsoft OLE DB Provider for ODBC drivers ，如果你事先已经建好了系统DSN的话，就可以直接在数据源中选中系统DSN的名字mydsn了，这样做似乎会有些问题。最好还是选择使用“生成连接字符串”，点击“编译”，便弹出数据源选择窗口，我们选用机器数据源标签，从里面可以选择我们已经建立了的系统DSN名字mydsn，然后确定。其实，你也可以重新创建一个新的系统DSN，这时你会看到，创建新的DSN的界面，就是ODBC的界面。（至于如何创建系统DSN我就不细说了）
这样我们的udlodbc.udl就建立了，用记事本打开看看，内容大致如下：
[oledb]
Provider=MSDASQL.1;
Extended properties= "DSN=mydsn;
DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;"
接下来和上面是一样的，在.asp程序中使用该.udl文件
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Open "File Name=c:udludlodbc.udl"
%>
那什么是这种情况下“非UDL方式”呢？当然也是把连接字符串写在程序中了
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "Provider=MSDASQL.1;
Extended properties=""DSN=mydsn;
DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;"""
%>
我们再根据ADO的默认情况，省略掉可以不写的部分，便成了以下的样子：
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DSN=mydsn;"
%>
这就是我们常说的系统DSN方法。
大家可以推导出文件DSN方法，以及非DSN方法都是如此
文件DSN方法，假设文件名为odbc.dsn
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "FileDSN=c:dsnodbc.dsn;"
%>
非DSN方法
<%
Set conn=Server.CreateObject("ADODB.Connection")
conn.Open "DBQ=C:Inetpubwwwrootaspadodbmydb.mdb;Driver={Microsoft Access Driver (*.mdb)};"
%>
好了，这些观点纯属个人见解！由于本人水平有限，望大家多多指教！
