Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ODBC on 64-bit systems
#1
an fyi for those folks emplimenting distributed systems.

if you'll be using cqc on a 64-bit OS, most likely would be Vista or Win 2k3 or 2k8, and you need db access ia ODBC connections, use the 32-bit version of the ODBC Management tool to configure your DSN's if you run into any problems with CQC accessing databases/seeing the system DSN's. - you'll most likely run into the problem if your db is on another system.

If you configure DSN's via the Administive Tools -> Data Sources (ODBC) interface, you'll be configuring 64-bit versions, which 32-bit applications can not use.

in vista, you can access the 32-bit version of the ODBC Management tool by launching c:\windows\system32\odbcad32.exe. on W2k3 it's located under c:\windows\syswow64.

you may find you need the following provider if using odbc on a 64-bit win2k3 box.
~~~ B01nk
Reply
#2
Hmmm... Given the nature of ODBC, you'd think that they could make it backwards compatible fairly easily. I wonder what the rationale behind that is?
Dean Roddey
Explorans limites defectum
Reply
#3
funny you ask. i actually used a credit on my MSDN account and called MS. here's the skinny...

"ODBC support was slatted to be depricated due to the lack of need to use ODBC connections. rather, DSNless connections are most often used to make support easier".

obviously, there is truth to this statement. ODBC connections aren't really used anymore, except with legacy or cross-platform db applications.

however, MS is now starting to realize that they can only "drop" so much support...so, there will be another release for oledb support called "Windows DAC 6.0" and they are releasing patches that can be installed on win2k3 to allow 32-bit apps to take advantage of the 64-bit os.

Would it be possible, to allow the use of provider strings in DB connections in CQC. that would make drivers and macros so much more extensible, if DSN's did not have to be created, rather the drivers/macros accessed the resources directly using provider strings. - pleaaaaaaaaaaaaaaaaaaaase dean.
~~~ B01nk
Reply
#4
Part of the problem is that ODBC drivers are implemented as DLLs which are loaded into your process space. These driver DLLs are not part of the OS, and may not even be provided by Microsoft.

Since a 64 bit process can't load a 32-bit DLL or vice-versa means you cannot have a totally seamless experience. 32 bit processes also 'see' a difference view of portions of the registry, and that is where the ODBC configuration is stored.

The same problems arise with in-proc COM objects. However, users come across the ODBC issue more often since they have to configure them, and all the documentation just directs you to the control panel.
Reply
#5
Quote:Would it be possible, to allow the use of provider strings in DB connections in CQC. that would make drivers and macros so much more extensible, if DSN's did not have to be created, rather the drivers/macros accessed the resources directly using provider strings. - pleaaaaaaaaaaaaaaaaaaaase dean.

So what's the deal with those? As far as ODBC being dropped, I'm not sure of the implications of that. Does that mean that MS is just blowing off the rest of the world and will require everyone to talk to their stuff directly? Or is ODBC in general being dropped by everyone in favor of something else, or what? We'd really like to have a portable way of talking to various types of databases.

Or is it just that their APIs are effectively ODBC anyway and therefore though they are dropping it, they aren't really dropping it because you can use their ODBC compliant APIs to access any database on Windows?
Dean Roddey
Explorans limites defectum
Reply
#6
ODBC was replaced with OLE DB and other APIs years ago. Smile Most newer products using ODBC are actually thunking through an ODBC of OLE DB-type driver level.

Dean Roddey Wrote:So what's the deal with those? As far as ODBC being dropped, I'm not sure of the implications of that. Does that mean that MS is just blowing off the rest of the world and will require everyone to talk to their stuff directly? Or is ODBC in general being dropped by everyone in favor of something else, or what? We'd really like to have a portable way of talking to various types of databases.

Or is it just that their APIs are effectively ODBC anyway and therefore though they are dropping it, they aren't really dropping it because you can use their ODBC compliant APIs to access any database on Windows?
Reply
#7
honostly, i feel it's simply MS strong arming their will. they've obviously changed minds if you review their roadmap for OleDB support, which clearly details a future release of what they call "Windows DAC 6.0"

interesting read regarding Windows DAC 6.0: http://msdn.microsoft.com/en-us/library/...S.85).aspx
~~~ B01nk
Reply
#8
pseigler Wrote:honostly, i feel it's simply MS strong arming their will. they've obviously changed minds if you review their roadmap for OleDB support, which clearly details a future release of what they call "Windows DAC 6.0"

interesting read regarding Windows DAC 6.0: http://msdn.microsoft.com/en-us/library/...S.85).aspx
So I went into the system32 (Win 7 64 bit) directory, ran it and it looked just like the 64 bit version, with mymovies already configured. Still doesn't connect - no obdc in sight in the driver. Does this mean no mymovies in 6 bit win 7?
Reply
#9
Here's another recent post on this:

Quote:I thought I would post on how I got around this issue.

First, I had to use the 32-bit version of ODBC to create the system dsn (odbcad32.exe. this is in your syswow folder).

I then changed CQC and the MyMovies SQL Server services to use admin accounts to log in.

At this point, CQC was trying to connect, but I was getting an error in the logs saying the account could not query the table.

Next, I had to install the SQL Server client tools, and I went into the DB, and added that admin user as a DBO for the MyMovies DB. this resolved the issue.
Dean Roddey
Explorans limites defectum
Reply
#10
Ron Haley Wrote:So I went into the system32 (Win 7 64 bit) directory, ran it and it looked just like the 64 bit version, with mymovies already configured. Still doesn't connect - no obdc in sight in the driver. Does this mean no mymovies in 6 bit win 7?

The c:\windows\system32 directory actually contains all your 64 bit DLLs, not 32 bit DLLs as the name suggests.

W7 does some funky remapping, such that if a process is running in 32-bit mode, C:\WINDOWS\SYSTEM32 maps to the real location of the 32-bit directory, and if a process is running in 64-bit mode, it maps to the 64-bit directory.

The 32-bit versions of system32 are located in C:\Windows\SysWOW64

So The 64-bit DLLs are in "system32" and the 64-bit ones are in "SysWOW64". Couldn't be simpler :-?
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Considering cqc, what is it's best complement of systems? rhosch 14 1,623 02-26-2019, 12:41 PM
Last Post: Dean Roddey
  Setting up ODBC for CQC IVB 8 2,103 01-21-2018, 09:35 PM
Last Post: potts.mike

Forum Jump:


Users browsing this thread: 1 Guest(s)