Vb6 系统DSN未在所有用户的远程桌面服务器（RDS）中工作

我正在运行一个VB6应用程序来生成报告。它在本地系统DSN中打印良好。但当我将应用程序的.exe放入RDS时，报告不是为系统DSN打印的，而是为用户DSN打印的。对于系统DSN，显示“无法打开SQL server”

我的努力- 1. 我尝试使用[WindowsDir]\SysWOW64\odbcad32.exe创建一个32位DSN，但没有成功

二,。我试图将系统DSN的权限更改为以管理员身份登录，并使用regedt32为用户授予完全权限。但仍然存在与“无法打开SQL server”相同的错误。 但只要我创建了用户DSN，它就可以正常工作。请提供帮助。

如果此问题是由于为一个或多个用户创建的“过时”不正确的虚拟化系统DSN造成的，则更改实际系统DSN并不重要。对于这些用户，在传统模式下运行的程序将继续看到其虚拟化副本

系统DSN存储在以下位置：

HKEY\u LOCAL\u MACHINE\Software\Odbc\Odbc.ini\Odbc数据源

。。。但虚拟化条目最终会出现以下情况：

“

HKEY\U用户\\u类\VirtualStore\Machine\Software\Odbc\Odbc.ini\Odbc数据源

。。。根据

因此，清除虚拟化注册表项（删除它们）以取消对真实DSN的屏蔽可能需要大量的注册表篡改。通过创建一个脚本或小程序，在每个损坏的用户ID下运行一次，可以最容易地做到这一点

或者只是重新格式化启动驱动器，重新安装Windows

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

最终解决方案（清理机器后）可能是：

• 完全停止使用DSN。它们已经被弃用了很长一段时间，这就是为什么我们有DSN较少的连接字符串。当硬编码连接不实用时，可以轻松安全地存储在INI文件等位置。我们也有很多年了
• 处理程序中的appcompat问题，然后将清单添加到程序中，使其以“UAC感知”模式而不是传统模式运行。这就避免了此类混乱且难以修复的灾难

---

此VB6应用程序是否在传统模式下运行（没有带节点的清单）？如果是这样，那么到现在为止，您可能已经为一个或多个用户提供了旧的不正确系统DSN的虚拟化副本。在你清理掉它们或停止在传统模式下运行之前，你所做的任何事情都不会使程序看起来像真正的程序。感谢Bob77的回复，同时，如何清理它们？我已经删除了那些DSN，并尝试再次创建，但它对我来说不起作用。是的，我更改了连接字符串，它工作正常，向DSN说再见。谢谢Bob77:-）