据我所知，实体框架等数据库连接技术会自动打开和关闭连接以增强可扩展性。 (Managing Connections and Transactions)
例如，使用 asp.net mvc 的表单和实体框架将连接以检索记录，它们将立即断开连接并保持断开连接，直到我修改控件中的数据并保存它。
我想知道相同的行为是否适用于通过 odbc 链接到 SQL Server 的 access 2013 表单。检索到记录后，在我下一次操作之前连接是否关闭，或者在我关闭表单之前连接保持打开状态？行为是否可配置？
【问题讨论】：
标签： entity-framework ms-access
连接的事实或存在不会改变或增加典型应用程序的可扩展性。因此，如果您有 10 或 1000 个连接，而这些连接没有做任何事情，那么 SQL Server 没有做任何工作，因此在这些典型情况下不会增加可伸缩性。
而且经常有额外的网络聊天来打开连接拉数据，关闭连接。
然后，当您将数据写回时，您再次有 3 个步骤。所以你再次打开连接，打开表，写入数据，然后关闭表！
事实上，保持连接打开意味着您不会浪费网络带宽打开和关闭连接！
数据集断开的主要原因是，当您的连接状况不佳或不太理想时（例如通过互联网或咖啡店的 Wi-Fi），此类连接的可靠性要高得多。在这些情况下，如果打开连接命令失败，则连接不会发生，并且您不会提取任何数据。如果在重新尝试连接时发生了一点时间延迟或重试，那么没什么大不了的。因此，您获取该数据并关闭连接。
但是，如前所述，这种打开然后关闭经常会导致额外的开销。然而，考虑到互联网的工作方式（与典型的办公网络相反），这种断开连接的方法在很大程度上是通过互联网提取数据或使用 Wi-Fi 之类的东西时的常态。因此，该方法是一种预期会发生并且可能发生轻微断开连接的方法。
这个 3 步过程的第二个“常见”原因是其他开发平台“促进”使用断开连接的数据，因为表单未绑定到实际数据表（或绑定到查询）。这种断开连接的方法的缺点是您通常必须编写代码将数据拉到客户端，然后将数据从记录集对象呈现到表单。结果是需要大量额外的工作来编辑表单中的数据。因此，预计典型的 asp .net 应用程序的成本是在 Access 中编写该应用程序的 5 倍甚至 10 倍。
在 Access 绑定表单模型的情况下，它消除了开发人员必须对数据提取和编码进行编码，并消除了开发人员将数据提取到某个对象中，然后关闭该连接的需要。 Access 与 SQL 服务器建立连接后，该连接将保持打开状态，直到您关闭 Access 应用程序。
由于绑定表单模型，保持连接打开和活动具有快速应用程序开发的优势。因此，您无需编写代码从服务器中提取数据，然后将该数据从某种类型的对象传输到表单中。
因此，Access 方法的缺点与可扩展性几乎没有关系（如果有的话）。缺点是 Access 根本无法很好地处理连接中的简单中断。
因此，如果您在 Access 中构建一个绑定到一个包含 100 万条记录的 SQL Server 表的表单，并使用 InvoiceNumer = 12356 的 where 子句启动该表单，那么 Access 是智能的，并且只会拉下 ONE从 SQL 服务器记录。因此在可扩展性和性能方面，使用非连接系统而不是 Access 中的绑定连接模型不会导致性能差异。
但是，由于 Access 使该连接保持打开状态，因此该连接中的任何中断都将导致 ODBC 错误。更糟糕的是，在使用绑定表单时，Access 无法从此类错误中恢复——您唯一的办法是重新启动 Access。
当然可以在 Access 中构建未绑定的表单，但这不是 Access 的设计方式。事实上，如果要在 Access 中采用断开连接的数据模型，那么 Access 是错误的工具，因为这种方法没有向导或“开发人员帮助”。所以说 .net 有围绕断开系统构建的向导，而 Access 有围绕连接系统构建的工具。如果您在 Access 中构建未绑定的表单，那么许多使 Access 成为如此出色的快速应用程序开发工具的功能都会丢失。因此，绑定的 Access 表单具有许多您在 .net 表单中找不到的额外事件。
因此，Access 中的绑定表单方法损失的不是可扩展性或更好的性能，而是简单的易于开发是 Access 开发方法带来的主要特征和收益。
开发人员仍然需要并且应该限制拉入表单的记录数量（通过使用表单“where”子句。 （所以 .net 表单没有 where 子句这样的放纵）。
因此，主要缺点是 Access 无法从 ODBC 断开连接中恢复，因为它旨在保持此类连接打开。
【讨论】：