我對這個話題進行了廣泛的研究，並與我的同事進行了深入的討論。與Jet/ADO立即關閉連接真的很明智嗎？
普遍的共識似乎是，在需要立即關閉時數據庫連接，應運行結束。任何緩存/連接池應由數據庫驅動程序或其他層完成，但不能由應用程序本身完成。
但我有我的懷疑，當涉及到Jet/ADO。 Jet和/或ADO使用讀取緩存和懶惰寫入，這可能會導致"unsynchronized" connections。當然，我可以在每次使用JRO使用它們時重新同步連接，但這看起來相當麻煩，可能會導致性能下降。
我應該去關閉每個連接並重新同步所有的新連接的「最佳實踐」或者我應該只是因爲噴氣/ ADO怪癖的全球連接對象去了？
我認爲這是最好使用VB6的桌面應用程序的一個全球性的連接。理想情況下，數據庫驅動程序將管理連接池透明，但是當你使用的是與ADO噴射或DAO在VB6它不：在OLE DB Jet提供doesn't have connection pooling。我相信.NET提供者會這樣做。
我假定你的應用程序是一個桌面應用程序 - 你還沒有實際規定。我沒有經驗的IIS應用程序或COM +，所以我不知道什麼是最好的。可能不會使用Jet Access！雖然桌面應用程序很好。
大多數現代DBMS都提供ConnectionPool來管理連接。但是當你使用 connection.close（）; 你並沒有真正關閉連接，它只是將它返回給池，並且當你寫入時connection.open（）; 事實上，它不會創建一個新的連接，你只需在ConnectionPool中準備一個連接並使用它。
所以打開連接，並關閉它，每次你想傳遞查詢到DBMS是最好的方式，我不會導致性能問題，除了 你不能使用與幾個相同的連接數據讀取器SQLDataReader。
因爲不使用全局連接，尤其是在開發網站時 ，因爲當您的站點上流量很大時，它會在兩個用戶正在解析頁面時隨機拋出異常，導致2個數據讀取器嘗試使用相同的連接。
但是，Jet/ADO的同步問題呢？ – 2009-08-12 08:22:13
-1。我認爲這個答案是針對VB.NET而不是VB6的？ SQLDataReader絕對是一個.NET的東西。並且Jet的ADO OLE DB提供程序*不提供連接池，儘管我認爲.NET提供程序可以。 http://support.microsoft.com/kb/191572 – MarkJ 2009-08-12 08:46:09
對不起，我沒有注意到它標記爲vb6。 – 2009-08-12 09:01:29
最後兩個大VB6 + ADO + Access數據庫引擎的應用程序我的工作（兩支不同的球隊/僱主）使用相同的方法：
ADODB.Connection開放ADODB.Recordset使用Set rs.ActiveConnection = Nothing之一與Jet/ACE的問題是，噸他創建鎖定文件（* .ldb）可能會導致嚴重的性能損失。另外，如果LDB已經存在（因爲另一個用戶已連接），設置鎖定可能需要很長時間。
因此，您希望儘量減少應用程序連接的次數，因爲您可能會浪費時間不斷重新創建並重新連接到LDB文件。
在Access應用程序中，很多程序員在maintain a persistent connection中都很常見。
通常的建議是以隱藏形式打開表格或在表格上打開記錄集。我更喜歡初始化指向後端的數據庫變量。託尼在引用的文章中的反對意見對我來說似乎是微不足道的 - 解析連接字符串並不困難，例如Mid（CurrentDB.TableDefs（「MyLinkedTable」）。Connect，11）。
在非訪問上下文中，您有同樣的問題，因爲這是Jet/ACE數據庫引擎問題。當然，維護打開連接的特定方法會有所不同，但重要的是保持打開狀態意味着數據庫引擎對鎖定文件的爭用較少。
儘管我同意Jet可能不是基於Web的應用程序的最佳數據存儲，但它對於VB6應用程序可以很好地運行，原始海報就是這種情況。因此，-1。 – 2009-08-14 01:09:04
@David：VB6用於IIS應用程序和COM +。原始帖子使用「應用程序」，這意味着它是一個桌面應用程序 - 這就是爲什麼我第一次 - 但它也使用「層」，這對我暗示在IIS或COM +。 – MarkJ 2009-08-14 11:22:48
只是爲了澄清 - 我與許多使用VB6/Jet Access的用戶維護了幾個桌面應用程序，並且它的工作正常。 – MarkJ 2009-08-14 11:36:38