ADO啟動連接時出現問題怎么辦

這篇文章主要講解了“ADO啟動連接時出現問題怎么辦”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“ADO啟動連接時出現問題怎么辦”吧！

ADO啟動連接作為一個高效的.NET程序語言。其混合了函數語言和物件導向程序編制語言，并且***的適用于編程、算法、技術和探索性開發，因此可以在使用的過程當中感受到趣味性和吸引力。

在一個客戶機/服務器應用中，我們可以用好幾種方法把建立和初始化數據庫連接所需要的時間隱藏起來，使得應用程序既能夠打開連接，又不需要用戶等待應用程序啟動。首先，我們可以嘗試異步連接。

使用異步連接時，ADO啟動連接操作之后，不等待連接完成就把控制權返回給應用程序——這樣，應用程序就能夠接著執行大部份初始化操作，以更快的速度完成form_load事件處理。

如果關閉并重新建立連接的時間小于連接池釋放連接的時間，那么這個連接實際上是即時的。但在許多情況下（特別是用戶數量不多時），讓連接保持打開狀態更具有現實意義。在中間層組件或ASP頁面內部，如果數據庫查詢多次重復出現，我建議你讓Connection對象保持打開狀態。

另外一個改進連接性能的辦法是，避免使用帶有DSN的ODBC。在Microsoft，ODBC已經轉入了Quick Fix Engineering（QFE，快速修理工程）狀態，它意味著：除非發現重大BUG，該公司將不再在ADO啟動連接或它的驅動程序上花時間。另外，考慮性能和部署問題時，ADO啟動連接也是一個必須關注的問題。DSN必須安裝到客戶系統上，要求進行注冊表查找，與OLE DB連接相比，

它建立連接所需要的時間更長——特別是當你用直接編碼的方式指定ConnectionString時，這一點尤其突出。從實際效果來看，避免使用DSN降低的系統開銷很有限：如果完全取消連接建立過程，對于每個連接，你也許能夠剩下二到五秒時間（假設數據庫連接池中已經沒有連接）。然而，如果你的應用程序需要頻繁地建立連接，節省的時間累計起來就很可觀了。

建立數據庫連接的時候，你要選擇一個數據提供者。Microsoft建議我們使用ADO啟動連接提供者替代默認的ODBC提供者。對比***的OLE DB本地提供者和功能類似但較早的ODBC提供者，我感到前者令人不愉快的意外之事較少。但無論是哪種情況，你都應該在決定使用某個新的提供者之前對應用進行完整地測試——代碼的性能、支持的功能、行為方式都有可能發生變化。

在中間層和ASP中，在保持連接打開的情況下，我們不能（從實踐來看）創建出可伸縮的組件——至少在多次調用之間是這樣的。一般地，當IIS引用和釋放組件、ASP頁面的實例時，組件和ASP頁面被頻繁地裝入、丟棄。由于基于ADO的代碼每次執行時都必須建立、使用、釋放數據庫連接，最小化連接復雜程度的策略對性能的提高程度達到了可明顯測量的程度。在這些情形下，

對于我們連接數據庫的速度來說，ADO啟動連接連接/會話池有著重要的意義。如果你為Command對象的ConnectionString屬性指定合適的值（即，每次使用同樣的服務器、初始目錄、登錄ID和其他參數），那么，連接已經打開且處于可用狀態的機會很大。如果連接池中能夠找到匹配的連接，連接（或重新連接）的時間將接近0（通常小于250 ms）。

然而，如果ADO（或VB）代碼不釋放Connection對象，或者，我們在不同的實例之間改換了ConnectionString，OLE DB必須每次建立一個新的連接。如果出現了這種情況，我們將很快耗盡連接池內可用連接的數量。要確保連接被釋放，我們必須在關閉連接之后把Connection對象設置為Nothing。另外，ADO啟動連接不要在Recordset Open方法中使用ConnectionString，而是以獨立的方式打開Connection對象；這樣，當我們要關閉Connection對象以及要把它設置成Nothing的時候，引用它就很方便了。

感謝各位的閱讀，以上就是“ADO啟動連接時出現問題怎么辦”的內容了，經過本文的學習后，相信大家對ADO啟動連接時出現問題怎么辦這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！