0

我正在为报告运行 VB 6 应用程序。使用 System DSN 在本地打印效果很好。但是当我将应用程序的 .exe 放入 RDS 时，报告不是为系统 DSN 打印，而是为用户 DSN 打印。对于系统 DSN，其显示 - “无法打开 SQL 服务器”。

我的努力- 1. http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb2ced17-9dd3-40e4-b5b6-dd773ee7001c/system-dsn-on-rds-server 我尝试创建一个 32位 DSN 使用 [WindowsDir]\SysWOW64\odbcad32.exe，但对我不起作用。

2. http://www.tek-tips.com/viewthread.cfm?qid=341776 我尝试更改以Administer 登录的System DSN 的权限，并为使用regedt32 的用户授予完全权限。但仍然与“无法打开 SQL 服务器”相同的错误。但是一旦我创建了用户 DSN，它就可以正常工作。请帮忙。

4

1 回答 1

1

如果这个问题是由于为一个或多个用户创建的“陈旧”不正确的虚拟化系统 DSN 造成的，那么更改真实的系统 DSN 将无关紧要。为这些用户以旧模式运行的程序将继续看到他们的虚拟化副本。

系统 DSN 存储在：

HKEY_LOCAL_MACHINE\Software\Odbc\Odbc.ini\Odbc Data sources

...但虚拟化条目最终位于：

'HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\Odbc\Odbc.ini\Odbc Data sources

...根据注册表虚拟化。

因此，清除虚拟化注册表项（删除它们）以揭露真实的 DSN 可能需要大量的注册表操作。您可以通过创建在每个损坏的用户 ID 下运行一次的脚本或小程序来最轻松地做到这一点。

或者只是重新格式化引导驱动器并重新安装 Windows！

这甚至没有涉及 WOW64 注册表重定向的可能问题，这是一个不同但类似的问题。为什么不停止使用陈旧笨拙的 ODBC？你真的是故意使用它吗？

最终修复（清理机器后）可能是：

  • 完全停止使用 DSN。它们已被弃用很长时间，这就是我们使用无 DSN 连接字符串的原因。当硬编码连接不实用时，这些文件可以轻松安全地存储在 INI 文件等位置。我们现在也有UDL 文件很长时间了。
  • 处理程序中的 appcompat 问题，然后向它们添加清单，以便它们以“UAC 感知”模式而不是传统模式运行。这可以防止这种混乱和难以修复的事故。
于 2013-06-23T19:42:32.247 回答