为什么不建议使用一个公共OleDbConnection？解决该错误的另一种方法：打开太多的连接

        从您的描述中，我看到了一些可能导致您出现问题的问题： 嵌套连接： 您在彼此之间打开多个连接 打开/释放连接太快： 正如David-W-Fenton提到的那样，有了访问权限，每次打开/关闭单个连接时，都会创建/删除锁定文件。此操作非常慢，如果您快速打开/关闭应用程序中的数据库（执行大量原子查询），则可能会遇到此问题。 调查和解决问题的几种可能方法： 跟踪所有打开/关闭呼叫 添加一些调试跟踪，这些跟踪在您每次打开和关闭连接时显示。 它将允许您检测嵌套连接以及连接池被浪费的位置。 强制连接轮询 一个简单的\'fix \'可能是在您的连接字符串中显式设置连接池。它应该是默认的行为，因此也许它不会做任何事情来解决您的问题，但是它是如此简单以至于没有理由不尝试它：

OLE DB Services=-1

使用连接管理器类为您创建/释放连接。 用您自己的代码替换所有新的OleDbConnection的显式创建并关闭操作。 这样一来，您可以始终在整个应用程序中重复使用单个现有连接，并可以通过将行为集中在一个位置来快速调整整个应用程序。 那么，为什么不赞成使用单个连接呢？ 通常，您不应该在整个应用程序中保持连接打开状态，因为它们会迫使数据库服务器为您保留可用资源，并且这会减少可连接的客户端数量（始终有有限数量的可用连接）。 对于Access，虽然-一个没有服务器部分的基于文件的数据库-保持单个连接打开实际上是可取的，因为与打开新连接（创建锁定文件）相关的延迟。由于Access并不打算与大量并发用户一起使用，因此保持连接打开的资源成本不足以成为问题。 从简单的测试可以看出，保持连接始终处于打开状态可以使后续连接的打开速度提高约10倍！ OleDb驱动程序为您执行连接池，因此释放连接后便可以重新使用连接。 通过使连接和数据库操作保持在较小的范围内，使用线程时，您不太可能遇到并发问题。如果您使用到数据库的同一管道执行多个操作，则保持全局连接可能会成为问题。     

只是添加一些对我来说成功使用多年的信息（这有点类似于David-W-Fenton的建议） 首先，Microsoft Access（MDB，JET）的“ 2”不使用连接池。如Microsoft在KB191572中所述：   使用Jet OLE DB提供程序和ODBC驱动程序的连接不是   合并，因为这些提供程序和驱动程序不支持合并。 关于连接池，Ivan Mitev也有一篇博客文章指出：   那么这是什么意思？显然，存在   主动打开的连接进行了多次连接测试   关闭和打开完成快得多（2-3倍）。唯一可能的   我的解释是每次释放连接池   没有活动的连接。我必须做进一步调查   并在Microsoft数据访问中读取类似“池化”的内容   组件。或者也许只是为了保持一个打开的连接   保持游泳池的活力。这将是丑陋的，但仍然是一个很好的选择   足够的解决方法！如果有人有更好的主意，请分享。 微软在MSDN中指出：   ADO Connection对象隐式使用IDataInitialize。然而，   这意味着您的应用程序需要保留至少一个实例   始终为每个唯一用户实例化连接对象。   否则，当最后一个Connection对象时，池将被销毁   该字符串已关闭。 基于所有这些以及我自己的测试，即使使用Microsoft Access数据库，我对“模拟”连接池的解决方案也大致遵循以下步骤： 在应用程序生命周期中尽早打开一个ѭ2one到Access数据库。 像建议的那样，执行常规的SQL查询，并尽早处理ѭ2。 在应用程序生命周期中，应尽可能晚地处置一个常开的

OleDbConnection

。 这极大地加快了我的应用程序（主要是WinForms）的速度。 请注意，这也适用于Sqlite，它似乎也不支持连接池。