The 'Provider=Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. RRS feed

  • Question

  • This question has been asked before but not (as far as I can tell) since the June 2010 release of the 64bit Access Database Engine Redistributable found here:


    I am developing a web app on a 64bit Windows Server 2008R2 that reads uploaded Excel spreadsheets. I was delighted that Microsoft released the 64 bit driver - previously I had been forced to run in 32 bit mode - which caused issues for the reporting components in the App.

    I installed the 64bit file above and the app worked fine on my machine at home. When I install the 64 bit Access reader on my work server and attempt to run the app I get this error:

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

    I have verified that the 64 bit app is installed (it shows up in add/remove programs). What do I need to do so that the app can access it?

    I noticed in "Add/Remove Programs" that the version for the new ACE engine is 14.0.

    Should I have tried: 'Provider=Microsoft.ACE.OLEDB.14.0'?


    Friday, July 30, 2010 8:57 PM

All replies

  • Try to change target platform before compilation to "x86" instead of "Any CPU"
    Ali Hamdar (alihamdar.com)
    Sunday, August 1, 2010 9:08 AM
  • Ali,

    The new driver (at the link provided in my note above) is 64bit (finally!). It was released in June 2010. No need to change the target platform (in fact this will break it). But the installer doesn't seem to register it correctly in many cases. Any advice?



    Monday, August 2, 2010 12:56 AM
  • The documentation is incorrect. The version # is 12.0 and not 14.0.

    There is both a 32-bit and 64-bit version for 2010. You have to run the 64-bit install. In addition, you cannot have both the 32-bit and 64-bit version installed at the same time.


    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 2:06 PM
  • I have the 64bit version installed. The 32 bit version is not installed - the installer won't allow you to proceed if the other is already on the machine. I have tried 12.0 and it does not work.

    This site has been helpful: http://blogs.msdn.com/b/farukcelik/archive/2010/06/04/accessing-excel-files-on-a-x64-machine.aspx

    My configuration at home is exactly the same as my configuration at work. At home, I can use the 64 bit access reader through SqlServer using OpenRowSet and through the .NET web app when deployed to IIS - but not through the Visual Studio dev web provider. This doesn't make sense - but at least I see some success.

    Following the same steps at work, the reader doesn't work anywhere. Any ideas?

    • Proposed as answer by Sven Hansen Tuesday, May 10, 2011 3:53 PM
    Monday, August 2, 2010 2:19 PM
  • Now I'm able to open the Excel file through SqlServer using OpenRowSet instructions (see blog from my previous post).Further prrof that the 64bit Access reader has successfully installed. But I still cannot open using OleDb & .Net - what I really need. I get the same error that I have been getting all along (The 'Provider=Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.)
    Monday, August 2, 2010 2:35 PM
  • What is the target CPU platform for your application? Does it work for the x86 option?

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 2:46 PM
  • Target CPU is 64bit. The application uses reporting components that don't work if I switch to x86. I was excited (and relieved) to find out about the 64bit capability since it solves this problem - but it isn't picked up in the registry by .NET.

    I'm currently using the old 32bit provider - but have problems with reporting when I deploy to IIS. I haven't tried the new 32bit provider since it wouldn't address my need...

    Monday, August 2, 2010 3:08 PM
  • If you are able to use the Jet OLEDB Provider then your app is running 32-bit. I'm a little confused though since you mentioned IIS. Is this an ASP.NET application?

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 3:41 PM
  • You are right, this is an ASP.NET app (sorry that I didn't make this clearer). The Excel portion of the application works if I run in 32 bit mode. That is what I have been doing. But this breaks other parts of the app (the reporting part). To deploy all of the capabilities of the app in the most straightforward way, I need the Excel reader to run in 64bit mode. This is where I am seeking advice.

    Thanks for your help.



    Monday, August 2, 2010 6:15 PM
  • OK - I have explicitly set the Build setting for the app to x64 (it had been set to 'Any CPU'). Now I get this error when I attempt to run:

    Could not load file or assembly 'XlsReader, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.' So maybe my problem is that I can't get it to build to 64bit - and has nothing to do with the Excel reader itself - I think this is what you are suggesting.

    Can you help me figure out what I'm doing wrong?


    Monday, August 2, 2010 6:40 PM
  • I'm not familiar with XlsReader. Is this a third-party component?

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 7:24 PM
  • This is an ASP.NET app I have built to test the Access reader. It is bare bones - a single procedure that attempts to open an excel file using the reader. When I set build to 64bit - it will build but when I attempt to run I get this error...
    Monday, August 2, 2010 7:35 PM
  • At run time there is a problem loading the XlsReader library. Like I said, I don't know what that is so I'm going to need more information about this component.

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 7:50 PM
  • XlsReader is my ASP.NET app - the topic of this thread.

    Let me walk through the scenarios:

    I test 2 connect strings (CS):

    CS 1:       string excelConnStr = String.Format("Provider=Microsoft.Jet.OLEDB.4.0; Data Source={0}; Extended Properties =Excel 8.0;", filename);
    CS 2:       string excelConnStr = String.Format("Provider=Microsoft.ACE.OLEDB.12.0; Data Source={0}; Extended Properties=Excel 12.0;", filename);

    I test 3 Build settings (BS):

    BS 1:       Any CPU

    BS 2:       x86

    BS 3:        x64

    As expected for CS1 (old Access provider):

    BS1 & 2 work just fine.    BS3 gives Provider not found error - we expected this since it is a 32bit provider.


    But for CS2 (new 64bit access provider):

    BS1 & 2 gives Provider not found  - I don't understand why the setting Any CPU does not work. When I force a 64bit build (BS3), I get the unable to load assembly (the one I am attempting to build) error

    Monday, August 2, 2010 8:19 PM
  • OK, so let me get this straight before we proceed. First test with XlsReader ASP.NET app using scenarios BS 1 (pass), BS 2 (pass) and BS 3 (fail) is on a 32-bit Windows machine? Second test (all fail) is on 64-bit Windows machine?

    If this is true, do you have any other components in your application that are limited to 32-bit?

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, August 2, 2010 8:38 PM
  • Paul,

    Thanks for your patience. All tests were performed on a Windows Server 2008 R2 x64 machine. The variation between the tests for a given provider is the build setting for Visual Studio projects. There are no surprises for the old provider (CS1). The failure of the new provider (CS2) 32bit setting (BS2) is also no surprise - it is a 64bit provider after all.

    All of these test are merely to answer your questions - and are not surprising at all. I am surprised by the "Any CPU" failure CS2-BS1. I would have thought that Visual Studio would default to 64bit - but it appears that it must default to 32bit unless explicitly defined. This build setting throws the error in the title. If I could get to the bottom of this I could proceed.

    Equally puzzling is why the new provider (CS2) with a 64bit build setting (BS3) will not run after a build - throwing the "Could not load file or assembly..." error. Though this is a different issue than the previolus case (CS2-BS1), if I could get it to work I could proceed.

    If you could help me with either CS2-BS1 or CS2-BS3, I would be able to move forward and deploy my application



    Tuesday, August 3, 2010 12:58 PM
  • I think the issue is with the ASP.NET configuration under IIS. If you are using version 7.0 or higher you can configure apps to run in 32-bit and 64-bit mode independently of one another on the same server. You can set the "bitness" globally or per application pool. For example, if you set the Enable 32-Bit Applications property of an application pool to True then all apps that run in that pool will execute in WOW64 (32-bit sub system).

    I would double check your IIS application configuration to see if your app is running as 32-bit.

    Paul ~~~~ Microsoft MVP (Visual Basic)
    Tuesday, August 3, 2010 2:20 PM
  • Paul,

    We may have come to a dead end. I had already taken these steps while running the app using the old driver. The issue - I don't want it to run as 32bit. That was the whole point of obtaining a 64bit provider...   Thank you for your help

    Tuesday, August 3, 2010 10:48 PM
  • So that being the case, did you set it back to False for that particular application pool? If you didn't then it's not running as a 64-bit app (which is what you want).
    Paul ~~~~ Microsoft MVP (Visual Basic)
    Tuesday, August 3, 2010 11:03 PM
  • You can easily work with office software such as Access and Excel under 64 bit . released on June 2010 appropriate driver .
    I wrote a blog about this (in Hebrew), but you can get from it the links and see the solution or if there is a problem I will translate into english :


    * since i am not coming to this forum u can get me at the heb forum of microsoft:


    Tuesday, January 25, 2011 7:50 PM