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

Posted 2023-05-07

【中文标题】Microsoft Access ODBC 连接：连接字符串差异

【英文标题】：Microsoft Access ODBC Connections: Connection String Differences

【发布时间】：2018-09-27 16:08:47

【问题描述】：

使用以下内容：

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 连接，我认为这是我的网络设置的合适选择。这个参数从几个连接字符串中排除有问题吗？

【问题讨论】：

您是否怀疑这些连接字符串的变化会导致或促成您的 Access 数据库问题？如果是这样，您可以将它们标准化并检查该更改对其他问题的影响。一个简单的 VBA 过程可以管理连接：对于每个链接的TableDef，设置其Connect 属性，然后调用RefreshLink 方法。

我不确定。该数据库在过去一两个月内反复出现“无法识别的格式”错误……不好！我什么都试过了——编译VBA代码；重新链接所有 ODBC 连接；压缩和修复，然后反编译数据库；第三方分析仪；和我最不喜欢的选项，导入一个空白数据库。问题仍然会定期出现。在这一点上，我正在寻找任何不一致的东西。我有一些其他数据库也有类似问题，但没有一个数据库具有持久性。

【参考方案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）。

【讨论】：

Albert - 非常感谢您的详尽回答！我会尝试将您的建议付诸实践并报告！