3

For a while I was stuck trying to get a visual basic 6 app working in Windows 7. The last remaining snag was that it just couldn't find the DSN when starting up. On a hunch, I deleted the system DSN and created it exactly the same way, but in Users. Suddenly everything worked great. I couldn't beleive it so I tried to move it back to system thinking I may have had something wrong, but sure enough it was broken again.

I can't seem to find anyone else running into this in my google searches, but does any one have any ideas as to why this might happen?

I'de really like to go back to using the system DSN as that's easier to manage.

Thanks!

lowlevel
  • 188
  • 3
  • 9

1 Answers1

7

What happens if you start your VB6 application by right-clicking the icon and choosing "Run as administrator"? I suspect you would then see the System DSNs (which are presumably only visible to admin-level accounts).

Update: I think this will work - set up your system DSN by running this:

C:\Windows\SysWOW64\odbcad32.exe

I think the problem is that the default Win7 interface for configuring DSNs makes them 64-bit, but you need a 32-bit DSN to work with VB6. </PUREGUESSWORK>

MusiGenesis
  • 74,184
  • 40
  • 190
  • 334
  • No, that doesn't let me at systen DSN's. I have to run it as administrator anyway though... – lowlevel Feb 01 '11 at 21:33
  • That's the end of my guesses for this. FWIW, I'm currently maintaining a commercial VB5 app, and if I'd converted it to VB.NET 8 years ago like I should have, I would have been through all the pain already. – MusiGenesis Feb 01 '11 at 22:12
  • Appreciate the input! I've been trying to get approval to do a re-write, but... there always just seems to be something more important that I *HAVE* to work on. Like I said, it does already run as administrator and with a User DSN, so its more of an annoyance than anything. Hopefully someone has another idea! Take care. – lowlevel Feb 01 '11 at 22:20
  • I'm sure this was already answered in another thread. The wrong ODBC Admin tool is most likely the answer. Better yet stop using ODBC when possible, and use OLEDB Providers and .UDL files you keep in a folder under CommonAppData instead. – Bob77 Feb 01 '11 at 22:39
  • That did it! Thanks! (But I'm still left wondering why it worked in Users... ) – lowlevel Feb 02 '11 at 00:02
  • @lowlevel: there's probably some layer in Windows 7 that automatically reconfigures DSNs for 32-bit use, but only for User DSNs. I dunno. – MusiGenesis Feb 02 '11 at 01:04
  • "The 32-bit version of the ODBC Administrator tool and the 64-bit version of the ODBC Administrator tool display both the 32-bit user DSNs and the 64-bit user DSNs in a 64-bit version of the Windows operating system." http://support.microsoft.com/kb/942976/en-us – Bob77 Feb 04 '11 at 15:51
  • @Bob: thanks, that link explains the problem. Another relevant quote from it: "The SQLDataSources function that is called in a 32-bit application returns only system DSNs for 32-bit drivers but returns user DSNs for both 32-bit drivers and 64-bit drivers." Explains why the VB6 app (32-bit) does not see the 64-bit system DSNs but does see the 64-bit user DSNs. – MusiGenesis Feb 04 '11 at 16:08
  • @BobRiemersma sadly isnt ODBC becoming the preferred method in SQL Server 2012 again? (why oh why) – Yablargo Jul 30 '12 at 18:13