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;″