none
Why can't 32 and 64 bit Access Database Engine (ACE/OLEDB Dataproviders) coexist?

    Question

  • Why can't the 32 and 64 bit versions of the Microsoft Access Database Engine 2010 Redistributable (AccessDatabaseEngine.exe and AccessDatabaseEngine_X64.exe)
    both be installed on the same machine? 

    The fact that they cannot forces us to compile two different versions of our application; one specifically for x86 platform and one for x64 platform.  Then we have to somehow determine which version of the ACE driver is installed so we know which version (32 or 64 bit) of our application to install.  Life would be much simplier if we could just compile our app for the default AnyCPU and then both 32 and 64 dataproviders were allowed to be installed.

    If they have the 32 bit ACE OleDB dataprovider installed and then try running our app compiled for AnyCPU platform on an 64 bit system then they get the following error when we try to use the following connection string with OleDBConnection;

    New System.Data.OleDb.OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & clientPathMDB)

    "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."

    Again, I know that we can avoid this by targeting our app specifically for x64.  But I don't think we should have to.  Why can't 32 and 64 bit ACE coexist?

    What complicates matters even more is IF they have any other 32 bit Office component installed then they CAN NOT install the 64 bit Access Database Engine 2010 Redistributable (AccessDatabaseEngine_X64.exe).

    So if they cannot coexist then how to we determine which is installed so we know which version of our app to install?

    Tuesday, August 03, 2010 6:18 PM

Answers

  • Bzzzzt.

    I'm sorry but that's just not an answer to this question:

    Why can't 32 and 64 bit Access Database Engine (ACE/OLEDB Dataproviders) coexist?

    MS does not allow installing 32- and 64-bit versions simultaneously and have provided no technical reason for why this is so.

    moderator: please unmark this as an answer


    Per
    • Marked as answer by brandonwilhite Wednesday, October 20, 2010 4:45 PM
    Monday, September 13, 2010 7:27 AM

All replies

  • It's based upon the fact that Microsoft does not support the side by side install of 32 and 64-bit Microsoft Office 2010 or their dependent components. In addition, Microsoft recommends that, for now, customers use the 32-bit version of Office since many of the common Office Add-ins will not run in the 64-bit Office environment.

    Seems to me you can handle this in the installer or let the user decide whether to install the 32-bit or 64-bit version (assembly), or maybe both. 


    Paul ~~~~ Microsoft MVP (Visual Basic)
    Wednesday, August 04, 2010 10:04 PM
  • BTW, a quick check of the Registry for the ACE OLEDB Provider (32-bit) reveals the following keys:

    HKEY_CLASSES_ROOT\Microsoft.ACE.OLEDB.12.0\CLSID

    Value: {3BE786A0-0366-4F5C-9434-25CF162E475E}

    HKEY_CLASSES_ROOT\CLSID\{3BE786A0-0366-4F5C-9434-25CF162E475E}\InprocServer32

    Value: C:\PROGRA~1\COMMON~1\MICROS~1\OFFICE12\ACEOLEDB.DLL


    Paul ~~~~ Microsoft MVP (Visual Basic)
    Wednesday, August 04, 2010 10:13 PM
  • I'm sorry, but that's not a very helpful answer to the question.

    Q: Why can't the 32 and 64 bit versions of the Microsoft Access Database Engine 2010 Redistributable (AccessDatabaseEngine.exe and AccessDatabaseEngine_X64.exe) both be installed on the same machine?

    A: Microsoft does not support the side by side install of 32 and 64-bit Microsoft Office 2010.

    That's not answering, that's just repeating the question in other words.

    Is there anything in these technologies that prevent MS from supporting 32 and 64-bit drivers side-by-side or did they do it just to make life hard for developers :-)

    I'm assuming the first but haven't seen anyone from MS explain the underlying reasons for this seemingly arbitrary decision.

    Q: Why can't I do this?

    A: Because we don't support it.

    Q: Why can't you support it?

    A: Because we don't support it.

    etc...


    Per
    Wednesday, September 01, 2010 12:10 PM
  • Hi,

    I exactly cant say more on your issue of side-by-side installation of 32 bit and 64 bit packages on windows platform. But would like to point you out concept called as WOW which may create above mentioned issue.

    Definition: Many Win16 applications can run without changes on 32-bit editions of Windows, complete with the limitations of such applications compared with applications written for Win32. The operating system thunks 16-bit APIs to their underlying 32-bit equivalents in order to provide support for 16-bit pointers, memory models and address space

    For details about WOW (Windows On Windows) please refer to url below:

    I hope the above listed links can put more light on what Paul Clement is trying to explain.

    One more thing I would like to point is: while releasing(compiling, building) your binaries please set the target cpu mode as any. so that it becomes less painful (I hope this can answer your other questions).

    Please let us know your views on this.


    Manish Patil http://patilmanishrao.wordpress.com Posting is provided AS IS with no warranties, and confers no rights.
    • Marked as answer by Roahn Luo Tuesday, September 07, 2010 6:15 AM
    • Unmarked as answer by brandonwilhite Wednesday, October 20, 2010 4:44 PM
    Thursday, September 02, 2010 10:35 AM
  • Bzzzzt.

    I'm sorry but that's just not an answer to this question:

    Why can't 32 and 64 bit Access Database Engine (ACE/OLEDB Dataproviders) coexist?

    MS does not allow installing 32- and 64-bit versions simultaneously and have provided no technical reason for why this is so.

    moderator: please unmark this as an answer


    Per
    • Marked as answer by brandonwilhite Wednesday, October 20, 2010 4:45 PM
    Monday, September 13, 2010 7:27 AM
  • This is not just a pain for developers but for any user of an Vista64 or Win7 x64 machine. It makes you wonder why Microsoft came up with this *artificial* limitation/restriction as they are pushing users to move to 64-bit OS's.

    Now few people will actually use the 64-bit version of Office 2010 as that only brings more problems. However for a lot of other programs it makes sense to run in 64-bit mode on x64 Vista or Win7. However those programs will then require 64-bit Office drivers to use MSOffice files.

    The only suggestion I know, is to first install the 64-bit Office 2010 ODBC/OleDB drivers and after that the (32-bit) Office 2007 application suite (or drivers). That does mean that the 32-bit drivers have a different version number than the 64-bit drivers though.
    Wednesday, August 24, 2011 12:58 PM
  • If when you are trying to install AccessDatabaseEngine_x64.exe you get this message:

    Open your registry editor and find this key:
    HKEY_CLASSES_ROOT\Installer\Products\00002109030000000000000000F01FEC

    Rename 00002109030000000000000000F01FEC to .00002109030000000000000000F01FEC:
    HKEY_CLASSES_ROOT\Installer\Products\.00002109030000000000000000F01FEC

    Then try to install again, when done change the key to the original value:
    HKEY_CLASSES_ROOT\Installer\Products\00002109030000000000000000F01FEC

     

    That works for me, now I have 32 and 64 bit versions of Microsoft.ACE.OLEDB provider installed in my server.

     

    Friday, November 25, 2011 4:05 PM
  • Not really documented, but I did find a way to install both the 32-bit and 64-bit versions. Just add the command line argument "/passive" to the command:

    "C:\directory path\AccessDatabaseEngine_x64.exe" /passive


    Paul ~~~~ Microsoft MVP (Visual Basic)
    Tuesday, December 20, 2011 4:17 PM
  • The /passive trick won't work well: if office 2010 32 bit is installed and if 64-bit ace is installed with /passive, then **every** time you run Access 2010, you get an automatic installation routine that resets to the 32-bit drivers for office. 

    The situation may be different if you have office 2007 32-bit installed, as then there is less likely to be a direct conflict.  Of course, microsoft could probably fix this....

     

    • Proposed as answer by florin Nagy Friday, February 01, 2013 1:02 PM
    Sunday, December 25, 2011 7:14 AM
  • So effectively you can only have the 32-bit and 64-bit MS Office runtimes on the same machine, if you use different versions. That would most likely be the Office 2007 32-bit application suite and seperately the 64-bit Office 2010 runtime files.

    Since machines in the average enterprise would come with the Office suite installed by default, the workarounds to get the 64-bit Office 2010 runtimes setup next to an existing (32-bit) installation are very useful.

    Still why did Microsoft put these artificial barriers in place ? Especially people with a 32-bit Office 2010 application suite will have a problem, as the 32-bit and 64-bit drivers have the same ADO/OleDB/etc. identifiers.

    Wednesday, July 04, 2012 11:43 AM
  • I just recently ran into this situation. Furthermore, EVERY time you run Excel or Word, they also "reconfigure", and you can no longer create new folders in Outlook (tells you to reinstall Outlook - nice!), and your signon to LIVE says "Something went wrong...".

    This thread has been inactive for a while. Has anyone (i.e. MSFT) come up with someway that I can build a single C# application for CPU=ANY or even CPU=x64 that will work on different x64 machines, one with x86 Office and one with x64 Office? My boss did not read the caveat to use 32 bit Office and neither of us wants to reinstall the other version of Office, that being so much fun...

    Thanks, Dave


    Dave


    • Edited by Dave Kolb Wednesday, February 13, 2013 3:35 AM clarify
    Wednesday, February 13, 2013 3:32 AM
  • Setting CPU=ANY does NOT help because if you build CPU=ANY it runs 64-bit on an x64 machine so will not talk to 32-bit Office without the AccessDatabaseEngine_x64 drivers, and then Office starts doing weird things. You have to set the /32preferred flag (or whatever it is) and there is no preferred about it since now it always runs 32 bit and won't work on a different machine that has 64-bit Office and the 64-bit drivers. Catch-22 - MSFT did not think this one through. Basically, there is no way to build one C# app that will even run on x64 machines, much less x86 and x64 machines, where one machine has Office 32-bit and another Office 64-bit, w/o Office reconfiguring Word and Excel every invocation, or Outlook able to create new sub folders, or being able to log in to LIVE. Please tell me I'm wrong!

    Dave





    • Edited by Dave Kolb Wednesday, February 13, 2013 3:47 AM
    Wednesday, February 13, 2013 3:44 AM
  • Microsoft never intended to support the side by side installation of both 32 and 64-bit versions of Office. This includes the dependent components, such as the ACE OLEDB Provider. The setup and configuration checks for the Office apps were designed to prevent this.

    I would suspect that, as with many applications, you will need to deploy two versions of the app, one that targets 32-bit environments and one for 64-bit. In the .NET world that means one configured with the x86 platform option and one for x64 (under Build...Configuration Manager in VS). I don't see this as an issue, because technically you still only have one version of the app. You just generate two different assemblies.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Wednesday, February 13, 2013 1:49 PM
  • Well maybe you don't see this as an issue, but other people do -

    #1 There is no way to build an x86 and x64 binary at the same time other than a tedious manual process that modifies the solution back and forth.

    #2 There is no way to have a WIX installer install an x86 or x64 version based on the version of Office installed.

    #3 This wastes the concept of CPU=ANY.

    There are lots of issues and problems I'm sure MSFT had no intention of supporting which does not mean they shouldn't when it is a PITA for their users. The Configuration Manger (thx for telling me there was one) does not have a choice that says "build me two assemblies so that my app can work with either version of Office". And furthermore, the x64/ANY app will work with the x64 driver and the 32-bit Office data but breaks Office itself so this COULD be made to work, but the real answer is apparently MSFT does not WANT to bother to make it work, all intentions aside.


    Dave



    • Edited by Dave Kolb Wednesday, February 13, 2013 3:41 PM
    Wednesday, February 13, 2013 3:33 PM
  • Here's a workaround for installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable on a system with a 32-bit MS Office version installed:

    • Check the 64-bit registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths" before installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable.
    • If it does not contain the "mso.dll" registry value, then you will need to rename or delete the value after installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable on a system with a 32-bit version of MS Office installed.
    • Use the "/passive" command line parameter to install the redistributable, e.g. "C:\directory path\AccessDatabaseEngine_x64.exe" /passive
    • Delete or rename the "mso.dll" registry value, which contains the path to the 64-bit version of MSO.DLL (and should not be used by 32-bit MS Office versions).
    • Now you can start a 32-bit MS Office application without the "re-configuring" issue.

    Note that the "mso.dll" registry value will already be present if a 64-bit version of MS Office is installed. In this case the value should not be deleted or renamed.

    Also if you do not want to use the "/passive" command line parameter you can edit the AceRedist.msi file to remove the MS Office architecture check:

    • download and install Microsoft Orca:
      http://msdn.microsoft.com/en-us/library/windows/desktop/aa370557(v=vs.85).aspx
    • unzip the AccessDatabaseEngine.exe or AccessDatabaseEngine_x64.exe file
    • open the AceRedist.msi file in Orca
    • search for two table rows containing the "CheckOfficeArchitecture" action and drop these rows
    • save the updated AceRedist.msi file
    • you can now use this file to install the Microsoft Access Database Engine 2010 redistributable on a system where a "conflicting" version of MS Office is installed (e.g. 64-bit version on system with 32-bit MS Office version)
    • Make sure that you rename the "mso.dll" registry value as explained above (if needed)


    • Edited by Applied Maths NV Wednesday, February 20, 2013 3:35 PM
    • Proposed as answer by Dave Kolb Thursday, February 21, 2013 4:48 PM
    Wednesday, February 20, 2013 2:37 PM
  • Thanks so much "Applied Maths NV" - this worked great and also allows Outlook to create new folders.

    Dave

    Thursday, February 21, 2013 4:48 PM
  • You're welcome Dave.  Note that installing Microsoft Access Database Engine 2010 updates like Service Pack 1 may cause the "mso.dll" registry value to re-appear, and cause MS Office to start "re-configuring" again.  At least we know where to look to resolve the issue. 
    Friday, February 22, 2013 1:45 PM
  • "I would suspect that, as with many applications, you will need to deploy two versions of the app, one that targets 32-bit environments and one for 64-bit."

    Is a 64-bit Windows with 32-bit Office 2010 a 64-bit environment or a 32-bit environment?  We want to target the 64-bit "environment", but most customers seem to have 32-bit Office.  Seems like a big problem to me.

    Monday, February 25, 2013 9:59 PM
  • Yes, that is the essence of the problem. MSFT wants you to run 64 bit apps on a 64 bit system (or as CPU=ANY in the case of .NET), yet recommends folks install 32 bit Office, even on a 64 bit system. They should at least have an app.config option to have CPU=ANY run as 32 or 64.

    Dave

    Monday, February 25, 2013 10:04 PM
  • Great thanks to you, Mr Applied Maths NV!!! I just followed your instructions and get a good result.
    Friday, May 17, 2013 9:21 PM
  • Many times M$FT just doesn't get it. The workaround by Applied Math works fantastic yet M$FT and "Paul Clement the IV" are in denial it is even a problem...

    Dave

    Saturday, May 18, 2013 12:44 AM
  • Actually there are at least two workarounds. You just mentioned one of them.

    In any event, unless or until there is a native .NET Provider for Microsoft Access (which I would like to see), the issue will not be resolved through changes to Visual Studio/ADO.NET. Support for the coexistence of the 32 and 64-bit OLEDB Providers is controlled by those who run the Microsoft Office project.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Monday, May 20, 2013 12:35 PM
  • Bah! I gave up, and put all my (read-only) data in XML resource files.
    Thursday, June 13, 2013 8:25 PM
  • "Applied Maths NV" 's solution works...

    Dave


    • Edited by Dave Kolb Tuesday, August 20, 2013 2:56 PM
    Sunday, August 11, 2013 12:11 AM
  • The following method doesn't work for me. It still refused to install after I removed two rows containing the "CheckOfficeArchitecture" action

    *** Also if you do not want to use the "/passive" command line parameter you can edit the AceRedist.msi file to remove the MS Office architecture check ***

    Friday, August 16, 2013 6:01 AM
  • I just started taking visual basic 2012.Net seriously, but was face with the same problem stated here some time ago, but trust me the solution was not easy at first.

     

    However, after reading, trying to solve and understand why this problem exit in the first place I realised the only solution is to install the 32 bit version of Microsoft.ACE.OLEDB.12.0 before you could connect making the application database section versatile . 

     

    My developers here let’s try to be precise in answering each other’s questions since they form base for solution(Knowledge base support) to our new developers around.

    Secondly, I believe Microsoft wishes to allow our application to run on all Microsoft OS platform since 64 bit application is limited to its kind only whiles 32 bit plat form can work out on either 64 bit or 32 bit platform.



    • Edited by Paawizzy Tuesday, August 20, 2013 6:56 AM
    • Proposed as answer by Paawizzy Tuesday, August 20, 2013 7:08 AM
    Tuesday, August 20, 2013 6:53 AM
  • Without these dodgy workarounds, if I understand the situation correctly, no 64-bit application that uses Access databases will be able to coexist with A) 32-bit Office installations or B) any other 32-bit application that uses Access/Jet. Quite a few in the B) category spring to mind, including the application used to fill in tax returns online in Spain. 

    Is this the case?
    Wednesday, September 04, 2013 8:05 AM
  • Has anyone had any success with Applied Math NV's solution using 64-bit Office 2013, W7?

    In this case, following the installation of the 32-bit MSA 2010 redist, there is no:

    HKLM/SOFTWARE/Microsoft/Office/14/Common/FilePaths/mso.dll

    registry entry, but there are both:

    HKLM/SOFTWARE/Wow6432Node/Microsoft/Office/14/Common/FilePaths/mso.dll

    HKLM/SOFTWARE/Wow6432Node/Microsoft/Office/15/Common/FilePaths/mso.dll

    Following the procedure as written now and deleting/renaming:

    HKLM/SOFTWARE/Microsoft/Office/14/Common/FilePaths/mso.dll

    after installation of the 64-bit driver causes all SSIS/MSSQL operations using the driver to fail. 

    Has anyone had any success with this scenario?  

    What does the `/passive` switch actually do?

    Monday, March 10, 2014 3:18 PM