User DSNs are not recognized by ADO at all. See: How To Create a System Data Source Name (DSN) in Windows 2000.

A true System DSN turns out to be a special case in Vista: Creating System DSNs on Vista.

So while my virtualization comment turns out to be a red herring, it does mean System DSNs must be created by an elevated process or a runtime error results (and you get no System DSN).

Assuming you create the DSN elevated (the Vista ODBC Administrator control panel applet always requests elevation) you should be fine on that point.

Bottom line: I may have sent you on a wild goose chase.


In my mind though the real question is why you're using ODBC and DSNs at all though. This is a relic from olden times and adds a layer of inefficiency to boot! Most people tend to use the OLE DB Providers and DSN-less connections today, storing connection string parameters in INI files or the equivalent (app.config XML files) instead of the registry.


So this (System DSNs) is what led me to the registry as a source of your problem. Its use for application settings is deprecated in Vista and there is a maze of rules to navigate about when a registry key is written to (or diverted to a per-user virtual location) and what you get when you try to read it back (i.e. from where, a system location or a per-user location).

However all of this may be irrelevant depending on how you are setting your DSN. Yet we still have the case where the test succeeds while your application fails. Is there any more detail to this error message, like an exception number or hResult value?