18

这篇 wiki 帖子概述了一个问题和一个解决方案。我想为可能遇到类似问题的其他人发布此内容，因为我在其他地方找不到专门解决此问题的任何内容。

我们最近将 SQL Server 2000 数据库升级到 SQL Server 2005。服务器上的一个数据库是 MS Access 数据库的后端。MS Access 数据库使用直通查询，通过无 DSN 的 ODBC 连接到 SQL Server。

无 DSN 连接字符串的示例如下所示：

ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
    Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
    Trusted_Connection=Yes

升级后，我们发现用户无法运行直通查询，并显示以下错误：

ODBC - 连接到“SQL Server”失败

这最初似乎是一个权限问题，因为将 SQL 服务器登录的特权提升到 sysadmin 服务器角色可以缓解问题（但显然这不是一个很好的解决方案）。

在将登录名从 sysadmin 角色中取回后，我们发现通过 Management Studio 连接到 SQL Server 时，登录名可以执行存储过程。无法从 MS Access 中进行相同的登录。这表明 MS Access 在尝试执行存储过程时正在做的事情——而不是权限问题。

我们使用 Profiler 在服务器上运行跟踪，这表明 MS Access 在存储过程执行之前尝试执行以下命令：

DBCC TRACEON(208)

在执行存储过程之前，该命令似乎失败了。网络研究表明 DBCC TRACEON(208) 相当于使用 'SET QUOTED IDENTIFIERS ON' 命令，并且在 SQL 2005 中运行此 DBCC 命令的权限已被撤销。

经过进一步研究，我们发现对 MS Query 的引用存在类似问题，并且连接字符串的 APP 组件应从“MS Query”更改为其他内容。

凭直觉，我们更改了 ODBC 连接字符串的 APP 组件，并且 MS Access 不再尝试在执行存储过程之前执行 DBCC TRACEON(208)。

经过进一步测试，我们将问题追溯到 APP 组件中包含的“版权”符号：

APP=Microsoft® Access (Pass Through Query)

通过删除版权符号，连接一切正常，应用程序像以前在 SQL 2000 上一样工作。

希望这可以帮助其他有类似问题的人。

4

1 回答 1

1

这不是注册商标符号吗？

我相信您遇到了 sql server 2005 针对基于 odbc 的攻击的防御措施之一。由于互联网上没有任何关于它的信息，因此很可能是 MS 内部处理的。

于 2009-09-03T05:24:07.817 回答