System DSN is not working in Remote Desktop Server(RDS) for all users

Question

I am running a VB 6 application for a report. It prints well in local with System DSN. But when i put the .exe of the application in RDS , report is not printing for System DSN rather its printing for User DSN. For System DSN its showing- "Cannot open SQL server".

My Efforts- 1. http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb2ced17-9dd3-40e4-b5b6-dd773ee7001c/system-dsn-on-rds-server I tried with creating a 32 bit DSN using [WindowsDir]\SysWOW64\odbcad32.exe, but wont work out for me.

2.http://www.tek-tips.com/viewthread.cfm?qid=341776 I tried to change the permission of the System DSN as logged in as Administer and to give full permission for the user using regedt32. But still the same error as "Cannot open SQL server". But as soon i create User DSN, it works fine. Please help.

Answer 1

If this problem is due to "stale" incorrect virtualized System DSNs that have been created for one or more users then changing the real System DSN won't matter. Programs that run in legacy mode for these users will keep seeing their virtualized copies.

System DSNs are stored under:

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

... but virtualized entries end up under:

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

... according to Registry Virtualization.

So to clean the virtualized registry entries out (delete them) to unmask the real DSN could be a lot of registry fiddling. You might do this most easily by creating a script or small program that gets run once under each corrupted user ID.

Or just reformat the boot drive and reinstall Windows!

This is without even going into possible issues around WOW64 registry redirection, a different though similar problem. Why not just stop using creaky old clumsy ODBC? Are you really using it on purpose?

The ultimate fix (after cleaning up the machine) is probably:

• Stop using DSNs at all. They've been deprecated for a long time which is why we have DSN-less connection strings. These are easy and safe to store in places such as INI files when hard-coded connections are not practical. We've also had UDL files for ages now.
• Deal with the appcompat issues in your programs and then add manifests to them so that they run in "UAC aware" mode instead of legacy mode. This prevents such confusing and hard to fix mishaps.