ADO连接数据库的方法

ADO连接数据库通常有三种方法：System DSN Connection，DSN-less Connection 和 OLE DB Connection，这是大家都很熟悉的，它们的使用方法如下：

(注：三种方法的区别在于使用的是哪个关键字 - DSN,Driver,Data Source,Provider。UID，PWD 是 ODBC 的标记，User ID,Password 是 OLEDB 的标记。特别指出的是 Data Source 在 ODBC 标记中表示数据源，等同于 DSN，在 OLEDB 标记中表示服务器名或数据库名。)

'System DSN Connection

Set cnn = Server.CreateObject("ADODB.Connection")

cnn.Open "DSN=your_dsn;UID=user_name;PWD=password;"

'或者用 OLEDB 标记

cnn.Open "Data Source=your_dsn;User ID=user_name;Password=password;"

'DSN-less Connection

'以SQL Server为例

Set cnn = Server.CreateObject("ADODB.Connection")

cnn.Open "driver={SQL Server};server=server_name;uid=user_name;pwd=pwd;database=pubs"

'OLE DB Connection

'以SQL Server为例

Set cnn = Server.CreateObject("ADODB.Connection")

cnn.Open "provider=sqloledb;data source=server_name;initial catalog=pubs;user id=user_name;password=pwd;"

下面，我们讨论一下它们各自的性能。

从本质上说，System DSN 和 DSN-less Connection 都是通过 ODBC 与数据库进行连接的，它们之间区别不大(事实上也确实如此)。有很多人说 DSN-less Connection 要优于 System DSN Connection，对这一点我不反对。(是不是前后有些矛盾，刚说它们区别不大，现在又......)我曾经分别对这两种连接测试过，但是失败了。因为我的测试数据没有规律，根本说明不了问题(或许用假设检验能比较两者的性能，不过得算死)。于是我得出了结论：没有结论！后来在网上看到一篇文章 System DSN or DSN-less Connection? 算是有了答案。

结论就是(这是原文)：

These tests showed that DSN-less connection were slightly faster than System DSN Connections.The increase in performance was nothing monumental;the greatest performance boost was mere 13% faster with 64 concurrent requests.For one,two,or four concurrent requests,there was virtually no performance improvement.In fact,no noticeable improvement is seen in a DSN-less connection over a System DSN until there are 10 or more concurrent connections.

为什么？因为 System DSN 在连接时要读注册表。

现在只有OLE DB没有说了(打字真累)。OLE DB 比 ODBC 要高效的多。

根本不用测试，这个结论是显而易见的。如果你还有些怀疑，建议去看看 连接池(Connection Pooling)介绍 那里有 MDAC framework 的图示，从图中可以看出，经 ODBC 连接是 ADO-->OLE DB-->ODBC Provider-->ODBC-->driver-->数据库；经 OLE DB 是 ADO-->OLE DB-->DB Provider-->数据库。哪个更直接？当然是 OLE DB!

OLE DB 连接数据库比 ODBC 快，检索数据比 ODBC 快。所以，我建议每一个在网上安家的人：用OLE DB！

Set cnn = Server.CreateObject("ADODB.Connection")

'Connection string for SQL Server

cnn.Open "Provider=SQLOLEDB;Data Source=srvName;Initial Catalog=DBname;User ID=user_id;Password=yourPassword;"

'for Access

cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=db_path"

连接数据库就是这么容易！

Access数据库连接方式探讨　

　　如果你正在使用Access数据库,千万记住不要使用DSN系统连接。原因是，它们的速度非常之慢，因为它们要先经过ODBC，再由ODBC通过JET Drivers来接通数据库。

　　当你使用非DSN（ DSN－Less）连接的ASP时，JET Drivers可以直接被访问，从而使其各方面的表现都大幅度地提升，特别突出的就是原本在Access DSN上速度很慢的新版MDAC（乘法模数转换）会出现明显的性能提升。

　　如果你正在使用新闻组，那你应该听到如下劝告：“不要使用非DSN 连接”。这条规则来自那些曾经长期使用DSN的用户的实际经验。至于具体的理由和解释嘛，正如一则故事里说的那样……理由太古老了，以至于我们已经说不上来了。呵呵。

　　就我个人的经验而言，我的工作中常有一些Web应用，在这些站点的数据库同时被20到30个用户使用着，仍然运行良好。数据库的工作状态取决于用户对数据库的访问量，如果没有这个限制，更多的用户同时使用也不会成为问题。如果你有足够的资源，你可以使其首先SQL化；但如果你没有，那就请试一下Access。如果有必要，你可以在以后随时将其扩充为一个SQL数据库，只需要对你的编码做一点小小的改动。

　　每天我都使用SQL数据库和ACCESS，所以我对两者都有评价的基础。公平的说，他们各有长处。 　　这里有一个小故事：

　　有一次，当我们把服务器升级到MDAC 2.1以后，一连串的使用Access驱动的站点开始报错：“Too Many Client Tasks（太多客户作业）”。在研究这种情况的时候，我在微软的站点发现了一篇文章，里面说使用Access的DSN系统其状况是非常“恐怖的”。可惜现在我已经找不到这篇文章了。不然我可以提供一个链接给大家。

　　在试验了各种方案仍然无效以后，我最后只好把一些较大的站点从DSN改为非DSN连接。倾刻之间，速度提升了，错误信息也没有了。虽然新的MDAC仍然有更令人头痛的问题，但是至少现在的Access数据库站点在同等访问量的前题下有了10倍于以前的速度。速度的提高又使用户可以更快地获得所需资料，从而使同时访问的用户数量不会太高，这就避免了Access无法处理的过量用户访问的情况的发生。从相同服务器上运行的Access数据库的总量来看，ODBC Access 看上去也好像比以前的负荷增大了。我也曾在没有升级为MDAC的驱动器上试验过这种改变，速度同样得到了提升。所以从现在开始，我的所有Access设计都是非DSN的。尽管我的大多数设计在工作中是不会用到Access的。

　　把你的DSN改为非DSN的吧。为你自己而做出这样的尝试。如果你发现那没什么用，它也不会对你造成任何的伤害。同时访问的用户越多，你越容易察觉到速度差异。

　　这里是一个非DSN连接的普通例子，假定这种方法可以直接访问ACCESS驱动器，DataConn.Open ″DBQ=″ ＆ Server.Mappath(″..／_database／database.mdb″) ＆ ″;Driver={Microsoft Access Driver (＊.mdb)};″

　　另外下面还有另一种途径，可以更直接地访问到JET。我要先说，这两种方法都比DSN 的表现要好许多。但我仍然发现了两者间一点小小的差别。这种更好一点点（只是一点点）的方法，以Access97为例，与JET的直接连接，

　　DataConn.Open ″Data Source=″ ＆ Server.Mappath(″..／_database／database.mdb") ＆ ″;Provider=Microsoft.Jet.OLEDB.3.51;″

　　还有Access 2000的例子：

　　DataConn.Open ″Data Source=" ＆ Server.Mappath(″..／_database／database.mdb″) ＆ ″;Provider=Microsoft.Jet.OLEDB.4.0;″