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

I'm running a VB6 application for a report. This system prints well with DSN locally but When I apply the application in RDS. Exe, then the report system is printing instead of DSN for the printing but the user is printing for DSN. For the system DSN showing- "SQL Server can not open"

My efforts - 1. I tried to create a 32 bit DSN using [WindowsDir] \ SysWOW64 \ odbcad32.exe, but Did not work for me.

2. I tried to change the system DSN permission, as was logged in as an administrator and to use full regedt32 to give the user full permission. But still the same error as "Can not open SQL Server", but as soon as I create a user DSN, it works fine. help please.

If this problem is created due to "stale" incorrectly virtualized system DSNs one or the other More users then change the actual system DSN, it will not make any difference. Programs that run in legacy mode for these users, they can see their virtualized copy.

The system DSN is stored in the following:

HKEY_LOCAL_MACHINE \ Software \ Odbc \ Odbc.ini \ Odbc Data Source

. But virtualized entries are at the end of:

' HKEY_USERS \ & lt; User SID & gt; According to _Classes \ VirtualStore \ Machine \ Software \ Odbc \ Odbc.ini \ Odbc Data Source

...

To clean virtualized registry entries (delete them to unmask the actual DSN), the registry may be very negligible

or just reformat the boot drive and then again Restore!

This can be run without any scripts or small programs under every corrupt user id. Even in the potential problems around the WOW64 registry redirection, a similar problem though is different. Why do not you use old old clumsy ODBC? Are you actually using it on purpose?

The final correction (after cleaning the machine) is probably:

• Stop using DSNs, they have been depreciated for a long time, so we have a DSN- There are less connection strings. These are easy and safe to store in locations such as INI files when hard-code connections are not practical. Even now we have gone for ages.
• Deal with Epappat's issues in your programs and then add them to the manifest so that they participate in "UAC awareness" mode instead of legacy mode. It prevents such misleading and difficult accidents.