Documenting a problem with User DSN and System DSN having the

Documenting a problem with User DSN and System DSN having the

Post by UGFrLU1pbm » Sat, 24 Jul 2010 02:27:17


his is an interesting bug!!

Yes, I can reproduce the bug easily. Unfortunately, I can still repro this
issue with the latest ACE driver released with Office 2010.

I can only say that the only workaround is not to use the same name for both
user DSN and system DSN.

Thanks for reporting this bug to us. I will contact the appropriate team to
see whether this issue can be addressed.

btw, DSN is a recommended method to deploy the application, compared to
connection string. This is because the application do not need to use a
hard-coded connection string. In deployment environment, the ability of
changing the underlying data source (say, Access file) may usually be needed.

Thanks,
Ming.
WDAC Team, Microsoft.

P.S. This newsgroup will be out-of-support very soon. We recommend customers
to use the forum to ask ODBC questions in the
future, where you can find more experts (Forum is at:
http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/threads/)



"Mary Chipman [MSFT]" wrote:

 
 
 

Documenting a problem with User DSN and System DSN having the

Post by Mary Chipm » Sun, 25 Jul 2010 00:47:35

On Thu, 22 Jul 2010 10:27:17 -0700, Pak-Ming Cheung - MSFT


Recommended by whom? There is no necessity to store secure elements of
a connection string, such as user ID and password, on disk or in code.
DSNs can notoriously difficult to manage and deploy because the
information is hard-coded in them as well. Search on some combination
of "DSN connection string" for more information.

--Mary