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

据我所知，实体框架等数据库连接技术会自动打开和关闭连接，以增强可伸缩性。（）

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

---

我想知道同样的行为是否也适用于通过odbc链接到SQL Server的access 2013表单。一旦检索到一条记录，连接是在我的下一次操作之前关闭的，还是在我关闭表单之前保持打开状态？行为是可配置的吗

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

而且网络上经常会有额外的聊天来打开连接、拉数据、关闭连接

然后，当您写回数据时，您又有3个步骤。因此，再次打开连接，打开表，写入数据，然后关闭表

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

数据集断开连接的主要原因是，在连接不良或不理想的情况下（例如通过互联网或咖啡店的Wi-Fi），这种连接的可靠性要高得多。在这些情况下，如果open connection命令失败，则连接不会发生，并且您不会提取任何数据。如果在重新尝试连接时出现了一点时间延迟或重试，那么就没什么大不了的。所以你抓取数据并关闭连接

然而，如前所述，经常打开然后关闭会导致额外的开销。然而，考虑到互联网的工作方式（与典型的办公网络相反），这种断开连接的方式在互联网上或使用Wi-Fi之类的东西时是很常见的。因此，这种方法是一种期望会并且可能发生轻微的断开的方法

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

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

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

因此，访问方法的缺点与可伸缩性关系不大（如果有的话）。缺点是连接中的一个简单中断根本没有被Access很好地处理

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

但是，由于Access使该连接保持打开状态，因此该连接中的任何中断都将导致ODBC错误。更糟糕的是，使用绑定表单时Access无法从此类错误中恢复–您唯一的办法是重新启动Access

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

因此，Access中绑定表单方法所失去的不是可伸缩性或更好的性能，而是简单易用的开发是Access开发方法所带来的主要特性和收益

开发人员仍然需要并且应该限制拉入表单的记录数（通过使用表单“where”子句）。 （因此.net表单没有where子句这样的特权）

---

因此，主要的缺点是Access无法从ODBC断开的连接中恢复，因为它是用来保持这种连接打开的。

回答得很好，非常感谢！为了确保我理解了所有内容，我有一个后续问题。如果没有向导，显示一条记录的向导创建的表单将在哪里“下载”屏幕上的记录或整个表？@artificer-“如果没有向导，显示一条记录的向导创建的表单将在哪里“下载”屏幕上的记录或整个表？”-两者都不是。Access将检索主键值，然后分批提取实际记录10次。有关详细信息，请参阅我的答案。Albert-“一旦访问establ”