何时MS Access 2013打开和关闭odbc连接？

Question

据我所知，数据库连接技术，如实体框架，自动打开和关闭连接，以增强可伸缩性。(管理连接和事务

例如，使用asp.net mvc和实体框架的表单将连接以检索记录，它们将立即断开连接并保持断开，直到我修改控件中的数据并将其保存。

我不知道这种行为是否适用于通过odbc链接到Server的access 2013表单。一旦检索到记录，连接是关闭到我的下一个操作，还是连接一直打开直到我关闭窗体？行为可配置吗？

Answer 1

连接的事实或存在不会改变或增加典型应用程序的可伸缩性。因此，如果您有10个或1000个连接，而这些连接没有执行任何操作，那么SQL server将不执行任何工作，因此在这些典型情况下不会增加可伸缩性。

而且经常会有额外的聊天在网络上打开连接，拉出数据，关闭连接。

然后，当您将数据写回时，再次执行3个步骤。因此，您再次打开连接，打开表，编写数据，然后关闭表！

事实上，保持连接打开意味着您不会浪费网络带宽打开和关闭连接！

断开数据集的主要原因是，当你有一个糟糕或不太理想的连接时(例如通过互联网或通过咖啡店的Wi)，这种连接的工作效率要高得多。在这些情况下，如果打开连接命令失败，那么连接就不会发生，而且您也不会提取任何数据。如果在重新尝试连接时发生了一些时间延迟或重试，那么没什么大不了的。所以你抓取数据并关闭连接。

然而，这个打开，然后关闭经常会引起额外的开销。然而，考虑到互联网的工作方式(相对于典型的办公网络)，这种断开连接的方式在很大程度上是通过互联网或使用Wi之类的方式提取数据的标准。因此，该方法是一种期望一个轻微的断开将发生，并可能发生。

第二个“公共”原因是其他开发平台“促进”了断开数据的使用，因为表单没有绑定到实际数据表(或绑定到查询)。这种断开连接方法的缺点是，通常您必须编写代码将数据向下拉到客户端，然后将数据从记录集对象呈现到窗体。结果是在表单中编辑数据需要做大量的额外工作。因此，预期典型的asp .net应用程序的成本是在Access中编写该应用程序的5倍甚至10倍。

在访问绑定表单模型的情况下，它消除了开发人员必须对数据进行编码和编码，并且不需要开发人员将数据拉到某个对象中，然后关闭该连接。一旦Access建立了到SQL服务器的连接，则该连接将保持打开状态，直到关闭Access应用程序为止。

由于绑定表单模型的存在，使得保持连接的开放性和主动性具有应用开发速度快的优点。因此，您不需要编写代码从服务器提取数据，然后将数据从某种类型的对象传输到表单中。

因此，访问方法的缺点(如果有的话)与可伸缩性没有什么关系。缺点是连接简单中断，Access根本无法很好地处理。

因此，如果您在Access中构建了一个绑定到一个包含100万条记录的SQL server表的表单，并且使用where子句InvoiceNumer = 12356启动该表单，则Access是智能的，并且只从server中提取一条记录。因此，在可伸缩性和性能方面，在访问中使用断开连接的系统而不是绑定连接模型不会导致性能上的差异。

但是，由于Access使该连接处于打开状态，因此该连接中的任何损坏都将导致ODBC错误。更糟糕的是，当使用绑定表单时，Access无法从这些错误中恢复--您唯一的方法是重新启动访问。

当然可以在Access中构建非绑定表单，但这不是设计访问的方式。事实上，如果要在访问中采用断开连接的数据模型，那么访问就是错误的工具，因为没有向导或“开发人员辅助”这样的方法。因此，假设.net有围绕断开连接的系统构建的向导，Access有围绕连接系统构建的工具。如果在Access中构建非绑定表单，那么许多使Access成为如此快速的应用程序开发工具的功能就会丢失。因此，绑定访问表单有许多在.net窗体中找不到的附加事件。

因此，绑定表单方法在访问中失去的不是可伸缩性或更好的性能，而是访问开发方法带来的主要特性和增益。

开发人员仍然需要并且应该限制拖入表单的记录数量(通过使用表单“where”子句)。(因此.net表单没有where子句那样的允许)。

因此，主要的缺点是访问不能从ODBC断开中恢复，因为它是为了保持这种连接的打开而设计的。