I have a doubt regarding the User DSNs.

I am packaging Access application for Terminal server.The application installs User DSNs.
Initially i tried to install user DSNs through registries which will try to self heal when the user logs in.

as self heal will not happen in Terminal server,i used tables for the ODBC DSNs.Now application is not self healing.User DSNs are also getting installed.Here i am not understanding how this works eventhough user DSNs also related to user info only.How msi will handle this internally.

Is it the correct way to install user DSNs for terminal server.

can anybody suggest on this....
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Why not try installing them as System DSN's. Works 9 out 10 times. It's the first thing I do, when an app. installs User DSN's. Well, maybe you did try and it doesn't work.

The users have roaming profiles I assume? If so, I don't understand how you could get it to work. I had to use vbscripts so the User information would write to their roaming profile.

Not sure I understand "used tables for the ODBC DSNs.

Answered 11/07/2007 by: gizsha
Purple Belt

Please log in to comment
Instead of registries i used ODBC tables in msi for the DSNs.
System DSNs i am not sure about how it works.If the application is designed in such a way to use User DSNs,then what will be the functionality if we use system DSNs.
Answered 11/07/2007 by: Eswari
Orange Belt

Please log in to comment
There is no difference, save for the fact that all users will see System DSNs in ODBC Administrator and only the user who created a User DSN will see that DSN. If the app cares i.e. it works with User but not System, it isn't using ODBC correctly, probably by reading registry entries directly. Throw it away.
Answered 11/08/2007 by: VBScab
Red Belt

Please log in to comment