ODBC System DSNs are not available in the ODBC Connection Manager - by Jamie Thomson

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


11
0
Sign in
to vote
ID 729631 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 3/8/2012 1:04:25 AM
Access Restriction Public

Description

I have just created an ODBC Connection Manager and am configuring it to point to one of my DSNs. I have checked the box labelled "Use User or system data source name", clicked the Refresh button, but the only DSNs that are listed are my user DSNs, system DSNs are not listed.

This is in RC0.
Sign in to post a comment.
Posted by Microsoft on 7/11/2012 at 8:58 PM
Hi Jamie,

We're going to resolve this issue as "Won't Fix". This issue is related to 32/64 bit version of the software. A simple workaround exists. You can add your system DSN using both odbcad32 and odbcad. Hopefully this will minimize the impact that this behavior has on your development.
Thank you for your feedback. If you have more concerns, we're glad to hear from you.
Posted by Phil Brammer on 3/15/2012 at 10:05 AM
Yes, Jamie use the 32-bit ODBC admin console to add your system DSNs as well as the 64-bit version.
Posted by troy99 on 3/12/2012 at 3:08 AM
Does this help?

http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/685eacc1-a670-42d4-8392-924230fa90cb
Posted by dcohen24 on 3/9/2012 at 9:37 AM
I've been using odbc on Sql 2008 and jump between 64 bit and 32 bit quite a bit.

Im 99% sure that the problem you are hitting is that visual studio (devEnv.exe/ Bids / whatever you want to call it) is running as a 32 bit application. Because it is a 32 bit app, it looks for the System DSNs created in ODBCad32.

However, when you switch over, and execute the same package using dtsexec on your production server it will in fact run in 64 bit mode (assuming its in program files, not program file(x86) ).

The end result of all of this is as follows:
On dev Machines the DSN must be entered as a system dsn using odbcad32.
On Prod machines where the scripts will eventually be executed you'll need the DSN in odbcad (the 64 bit version).
For simplicities sake, I always enter them in both places
Posted by Jamie Thomson on 3/9/2012 at 1:22 AM
Interesting, thanks thasteve.
Posted by thasteve on 3/8/2012 at 8:11 AM
i think it just doesnt like the ones created under 64bit os using the obcad32 i can see and use system dsn in connection manager