Microsoft.ACE.OLEDB.12.0 Provider Is Not Registered On The Local Machine | Fix It Fast

Guide / By

Microsoft.ACE.OLEDB.12.0 Provider is not registered on the local machine means your app can’t find the Access Database Engine driver it needs.

You’ll see this message when code tries to open a connection with the ACE OLE DB provider, most often to read an .accdb or .mdb file, or to treat an Excel file as a database. The call fails before any query runs. That tells you the problem is driver discovery, not your SQL.

This article walks you through a clean, repeatable way to identify what’s missing, install the right component, and confirm the provider loads under the same bitness and account that runs your app. You’ll leave with a checklist you can reuse on servers, desktops, and CI build agents.

What This Error Means And Why It Shows Up

ACE is a COM-based provider. When you write a connection string like Provider=Microsoft.ACE.OLEDB.12.0;, Windows looks in the registry for that provider’s COM registration. If it can’t find it, you get the “not registered” message.

Two situations trigger it most:

  • The provider is not installed — The machine never had the Access Database Engine (or Microsoft Office bits that include it).
  • The provider is installed in the other bitness — A 32-bit provider is present, but your app runs 64-bit, or the other way around.

There are also edge cases where the provider is installed and still not found by the process that needs it. That usually means the wrong app pool setting, a service running under a different account with missing access to the data file, or a locked-down server policy blocking installer writes.

Quick Checks Before You Install Anything

Run these checks first. They save time and keep you from installing a second driver that collides with Office.

  1. Confirm the file type — If you’re opening an .xlsx, you still need ACE, but your connection string needs the right Extended Properties and driver version.
  2. Check your app bitness — In .NET, look at your project target (Any CPU, x86, x64). In Python, check whether you installed 32-bit or 64-bit Python. In SSIS, check whether the package runs under 32-bit DTExec or 64-bit.
  3. Look for existing Office installs — A 32-bit Office install often blocks a straight 64-bit Access Database Engine install, and vice versa.
  4. Verify the provider name — Older setups use Microsoft.ACE.OLEDB.12.0; newer ones can also register Microsoft.ACE.OLEDB.16.0. Your code must match what’s installed.
  5. Test on the same machine account — A web app running in IIS and a console test you run as your user are not the same thing. The driver registration is machine-wide, but file access and path resolution can differ.

If any of these checks point to a mismatch, fix the mismatch first. If they point to a missing driver, install the Access Database Engine that matches your deployment.

Fixing The Microsoft Access OLEDB 12.0 Provider Error On Windows

Most fixes come down to installing the Access Database Engine (often called “AccessDatabaseEngine”) in the correct bitness. After that, you make sure the calling process runs in that same bitness.

Pick the right driver version and bitness

Use this table as a fast selector. It’s meant for the common case where you want Microsoft.ACE.OLEDB.12.0, but the same bitness rule applies to 16.0.

What runs your code Install this Common notes
32-bit app (x86), 32-bit SSIS Access Database Engine 32-bit Often works alongside 32-bit Office.
64-bit app (x64), 64-bit IIS app pool Access Database Engine 64-bit May conflict with 32-bit Office on the same box.
Any CPU app, runs 64-bit on server Access Database Engine 64-bit Set target to x64 or validate runtime picks 64-bit.
Build agent that only exports data Match agent bitness Keep it consistent across all agents.

If you control the app, the cleanest path is to decide on one bitness end-to-end, then stick to it. Mixed bitness setups are where this error keeps coming back.

Install the Access Database Engine cleanly

  1. Download the installer from Microsoft — Choose 32-bit or 64-bit to match your runtime. Store it with your deployment notes so you can rebuild servers later.
  2. Close Office apps — Excel and Access can keep files locked and can also cause the installer to fail mid-run.
  3. Run as admin — Right-click and run the installer with admin rights so COM registration writes succeed.
  4. Reboot if the installer asks — It’s boring, but it clears pending registry writes and file locks.

If the installer refuses to run due to an Office bitness conflict, you still have options. On many systems you can use the installer’s quiet switch to force install. That path works for some setups, but it can leave Office repair prompts later. If this is a shared workstation, weigh that risk. If this is a server built only for your app, the forced install route is often fine.

Microsoft.ACE.OLEDB.12.0 Provider Is Not Registered On The Local Machine When Office Is Installed

If you hit microsoft.ace.oledb.12.0 provider is not registered on the local machine with Office, match Office bitness when choosing the engine. That keeps updates calmer and reduces repair prompts.

Microsoft.ACE.OLEDB.12.0 Provider Is Not Registered On The Local Machine In Web And Server Apps

Servers add two extra wrinkles: IIS app pool settings and service identities. The driver can be installed and still not load if your process runs in the wrong bitness or can’t reach the file.

Match IIS bitness to the installed provider

  1. Open the app pool settings — In IIS Manager, select your app pool and open Advanced Settings.
  2. Set “Enable 32-Bit Applications” — If you installed the 32-bit engine, set this to True. If you installed 64-bit, set it to False.
  3. Recycle the pool — Restart the app pool so the worker process picks up the setting.

This one setting explains a lot of “works on my machine” cases. Your dev box may run a 32-bit IIS Express process, while production runs 64-bit by default.

Check the identity that reads the database file

  • Grant file permissions — Give the app pool identity read (and write if you update) access to the folder that holds the .accdb, not just the file.
  • Use a stable path — Prefer an absolute path outside your site root so deployments don’t overwrite data.
  • Avoid network shares when you can — If you must use a share, test under the same identity the app uses, and confirm the share and NTFS permissions both allow access.

File access problems usually throw a different exception, but it’s common to chase the provider error, fix it, then immediately hit “could not find file” or “permission denied.” Checking access early keeps the fix tight.

Connection Strings That Work And Ones That Break

Once the provider is installed, a bad connection string can still stop you. Keep the provider name exact and keep the properties aligned with the file you’re opening.

Access database connection string

A common Access connection string looks like this:

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\Data\\Sales.accdb;

If your file is password protected, add Jet OLEDB:Database Password=.... Keep secrets out of source control and load them from config at runtime.

Excel connection string

For Excel, ACE uses Extended Properties to describe the workbook format. A typical .xlsx read-only setup is:

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\Data\\Import.xlsx;Extended Properties="Excel 12.0 Xml;HDR=YES;IMEX=1";

When Excel imports behave oddly, it’s often due to type guessing. If the first rows in a column look numeric, ACE may treat the whole column as numeric and return blanks for later text values. A quick fix is to add a header row with clear text types, or to pre-clean the sheet before import.

Step-By-Step Fix Paths For Common Runtimes

Use the path that matches your stack. Each one ends with a quick verification step so you know you’re done.

.NET apps (C# or VB.NET)

  1. Set the project target — If you installed 64-bit, set Platform target to x64. If you installed 32-bit, set it to x86.
  2. Rebuild and deploy — Publish again so the output matches your chosen target.
  3. Run a minimal provider test — Open and close a connection with no query, then log success.

Python (pyodbc or ADO via comtypes)

  1. Match Python bitness — Install 32-bit Python with the 32-bit engine, or 64-bit Python with the 64-bit engine.
  2. Install the package you use — Keep your driver install and your virtual environment notes together for repeat builds.
  3. Test a one-file script — Run a script that only opens a connection and prints one row.

SSIS packages

  1. Decide 32-bit vs 64-bit execution — In Visual Studio, the designer often runs 32-bit. SQL Agent jobs often run 64-bit unless you choose the 32-bit runtime.
  2. Install the matching engine on the server — Don’t assume the dev box setup matches the server.
  3. Run the job and capture logs — Confirm which DTExec is used, then confirm the provider loads.

If a package runs in the designer and fails in SQL Agent, it’s nearly always a bitness mismatch, not a bad query.

Verify The Fix And Prevent Repeat Breaks

After you install the engine and align bitness, verify the provider is visible to the process that needs it. Do this once and you’ll avoid circles later.

  1. Run a provider list check — In PowerShell, you can query installed OLE DB providers with a simple script, or you can use a small .NET console app that prints provider availability.
  2. Open a connection under the real runtime — Test from the same Windows service, scheduled task, or IIS worker that runs in production.
  3. Log the exact provider name — Write the provider string into logs on startup so you can spot config drift fast.
  4. Pin your bitness choice — Don’t leave Any CPU to decide at runtime unless you fully control where it runs.
  5. Document the installer — Store the exact installer version, bitness, and install flags in your deployment notes.

If you still get the error after all of that, narrow it down with two checks. First, confirm the registry entries exist for the provider in the bitness you need. Second, confirm no virtualization layer is redirecting registry reads (older app compatibility settings can do this). Those checks are rare, but they save time on locked-down servers.

Finally, if you’re shipping software to many machines, consider moving away from Jet/ACE file formats when you can. A server-based database removes this driver dependency and makes deployments cleaner. If you must stay on Access or Excel inputs, treat the Access Database Engine as a first-class prerequisite and validate it during install or app startup.

When you see “microsoft.ace.oledb.12.0 provider is not registered on the local machine”, you now have a direct path: confirm bitness, install the matching engine, align the runtime, then verify under the real account. That fixes the message in the large majority of setups without trial-and-error.