Microsoft Access ODBC 连接：连接字符串差异

Question

使用以下内容：

• MS Access 2016，Office 365
• SQL Server 2012

我有 100 多个 SQL Server 表和视图通过 ODBC 连接链接到 Access 数据库。所有这些 SQL Server 对象都来自位于同一服务器上的两个 SQL Server 数据库。所有这些连接都已使用 Access 用户界面设置并通过链接表管理器重新链接。

我最近遇到了许多 Access 数据库问题，所以我正在用细齿梳子梳理所有问题。我注意到我所有的 SQL Server 对象的连接字符串有许多不一致的地方（见下文）。就这些对象的创建时间和连接字符串的格式而言，似乎也没有任何模式。

ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1  
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2  
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2  

连接字符串有这么多变体是否有问题？我做了一些研究（例如，谷歌搜索），但我在这方面的数据库方面没有太多经验。一些连接指定了“网络”，但其他连接没有。根据 connectionstrings.com (https://www.connectionstrings.com/define-sql-server-network-protocol/)，“Network=DBMSSOC”指定了一个 Winsock TCP/IP 连接，我认为这是我的网络设置的合适选择。这个参数从几个连接字符串中排除有问题吗？

Answer 1

我肯定会将所有链接表“协调”到同一个连接。

您可以使用链接表管理器来执行此操作，但可能代码更好。

您需要选择链接表管理器中的所有表，并确保单击提示以获取新位置。这将强制您创建（或选择）现有的 DSN。事实上，我会从“一个”给定数据库中选择所有表，然后单击“始终”提示以选择新位置。当您执行此操作时，所有将设置相同的链接和连接字符串。

有很多原因，其中一个原因是 Access 将为您缓存连接。因此，如果您对同一个数据库有“不同”的连接，您将拥有这些连接的多个缓存。这可能不会“太大”地影响性能，但它仍然是一个好主意。

如果您没有使用受信任的连接，那么您的连接字符串实际上不需要包含 uid/密码。 （但是，uid/密码的缓存需要精确的字符串匹配（减去 uid/密码）。在这种方法中，您可以在应用程序启动时执行“一次”登录，然后所有链接表（没有 uid/密码）现在可以工作了。但是，您在这里使用受信任的连接，所以这个提示 + 问题无关紧要。

在您的示例中，您使用的是受信任的连接，因此问题“远不是”令人担忧或问题。

我还强烈建议，当您从 Access 启动 ODBC 管理器时，您总是但总是使用 FILE dsn。这样做的原因是，Access 会为您将连接转换为无 DSN。

这意味着您现在可以将前端应用程序部署到任何工作站，并且您无需设置或复制任何 DSN 连接，甚至无需在工作站上进行设置。

所以我实际上会为一个给定的数据库选择所有表，（检查新位置的提示），然后创建一个 FILE dsn（无论如何它们都是默认值）。链接后，对指向其他数据库的所有其他表执行相同操作。再次重新链接。

结果将是一个无 dsn 的连接，因此您的应用程序将在网络上的任何工作站上运行，并且无需在每个工作站上设置任何类型的 dsn。

所以是的，您不必这样做，但随着时间的推移，一些表格似乎使用不同的 DSN 链接，它们应该被协调一致。而且，如果您曾经引入一些自动链接代码，您希望能够区分这两个数据库，而您的代码将很难通过不同连接的“大杂烩”来做到这一点。

因此，您可以使用链接表管理器来协调连接 - 只需确保从单个给定数据库中选择所有表，然后使用 FILE dsn 重新链接，结果将是一个没有 DSN 的连接（仅访问在链接过程中使用 DSN - 之后，访问不关心，也不使用甚至查看 DSN，或者即使它存在。

说了以上所有内容，尚不清楚此问题是否与您的错误或应用程序中的不稳定性有关。 （一个好主意是始终分发应用程序的编译版本 - （accDE，而不是 accDB）。