Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need some advice as I'm running into a problem and so far I have been unable to find a solution.

We have a set of reports developed in MS Excel that use a DSN file to connect to data sources to retrieve data. These work fine on 32bit and 64bit systems.

However, we are moving to a terminal server environment using Windows 2008 R2 64Bit

The reports fail to run using the DSN's within this environment if we only have the 32bit drivers installed and configured in the ODBC settings. The minute we install the 64bit drivers the software works.

Is there a way or method of getting Excel or the DSN file to NOT use the 64bit driver but force it to use the 32bit driver?

share|improve this question
up vote 2 down vote accepted

we are moving to a terminal server environment using windows 2008 R2 64Bit.

This per se won't cause you an issue, you have to install the 64-bit version of Microsoft Office 2010. You have to have a good reason for installing the 64-bit version, Microsoft installs the 32-bit version by default on 64-bit machines for a reason - stuff stops working.

Is there a way / Method of getting Excel or the DSN file to NOT use the 64Bit driver, but force it to use the 32bit driver.

No, but for connectivity within Office applications just install the 64-bit version of ACE and make sure your connection strings reference Microsoft Access Driver (*.mdb, *.accdb).

SQL Server and Oracle and a whole host of other common RDBMS' have 64-bit ODBC drivers, so I can't see how between 64-bit ACE and SQL Native Client/ODAC you can't connect to something.

If it still doesn't work, there's a general purpose mechanism for "proxying" x64 -> x86 via SQL Server linked servers in this forum post. Replace Microsoft.Jet.OLEDB.4.0 and other settings (to make it a linked server via ODBC, rather than ODBC) with your ODBC provider as appropriate.

share|improve this answer
Hi Todda, thanks for the reply regarding my problem, i was aware of being able to install 64bit drivers and getting the system to access them that way, however we are presently testing our systems within TS as a proof of concept before deploying it live. The idea of having to install the 64bit drivers alongside required 32bit drivers would have meant us re-testing applications to ensure that there was not compatibility problems between the two driver sets. Sadly without wanting to "tinker" with registry settings it appears this is the only real route so we are presently re-testing.. – Kristiaan Nov 22 '11 at 14:13

OP answered his own question

Sadly there is no way to-do what i want to-do, without a lot of very nasty and not 100% perfect reg hacks.

If you need to access 32bit ODBC data sources the application in question has to be 32Bit.

here is a link to just one forum post i found relating to this type of problem, it appears the only way i would be able to accomplish this is to remove the 64bit version of office and install the 32bit version instead of it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.