logo
search
Windows Integration Errors

Fix Microsoft ACE OLEDB Provider Not Registered Error in C#

Khadija KhanKhadija Khan Oct 13, 2026 868 views

Question details

A C# application throws an exception indicating that the Microsoft.ACE.OLEDB provider is not registered when attempting to connect to an Access database.

How to Fix the Microsoft ACE OLEDB Provider Not Registered Error in C#
Product
Visual Studio
Device & OS
not provided
Scenario
Connecting a C# application to a Microsoft Access database using the OLEDB provider.
Observed behavior
The application or Visual Studio environment reports that 'Microsoft.ACE.OLEDB.12.0 is not registered on the local machine' despite the Access Database Engine Redistributable being installed.
Before you start

Verify whether your installed Microsoft Access Database Engine Redistributable is the 32-bit (x86) or 64-bit (x64) version, as your C# project settings must strictly match this architecture.

Solution 1Recommended

Configure the Project Architecture to Match the Database Engine

Resolve the architecture mismatch by forcing your C# project to compile specifically for x86 (32-bit) or x64 (64-bit), instead of 'Any CPU'.

When a .NET project is set to 'Any CPU' on a 64-bit machine, it runs as a 64-bit process. If you only have the 32-bit Access Database Engine installed, the 64-bit process cannot load the 32-bit OLEDB provider, triggering the unregistered provider error.

1
Open project properties

In Visual Studio, right-click your C# project within the Solution Explorer window and select 'Properties' from the context menu.

2
Navigate to Build settings

Select the 'Build' tab located on the left-hand navigation menu to access the compiler settings.

3
Change Platform Target

Locate the 'Platform target' dropdown menu. Change the value from 'Any CPU' to 'x86' if you have the 32-bit Access engine installed, or to 'x64' if you have the 64-bit engine installed.

4
Rebuild and test

Click 'Build' > 'Rebuild Solution' from the top menu, then run your application to verify the database connection.

Configure the Project Architecture to Match the Database Engine
Visual Studio 2022 Limitation: Visual Studio 2022 is exclusively a 64-bit application. If you are using a 32-bit Access provider, the IDE's built-in Server Explorer connection test will fail because it cannot load 32-bit components. However, your compiled application will still work successfully when built for x86.
Free Microsoft Office alternative

Need a Reliable Office Suite? Try WPS Office

While troubleshooting your database integration errors in Visual Studio, you might also be looking for a fast, reliable, and cost-effective office suite for your documentation and data analysis needs. WPS Office offers a comprehensive alternative to Microsoft Office.

Seamlessly compatible with Microsoft Word, Excel, and PowerPoint formatsLightweight architecture that consumes minimal system resourcesAll-in-one tabbed interface for managing documents, spreadsheets, and PDFsFree to download and use for your daily office tasks
microsoft office alternative - wps office

Frequently Asked Questions

Why does the 'Any CPU' setting cause the Microsoft.ACE.OLEDB provider error?

When a project is set to 'Any CPU', it automatically runs as a 64-bit process on a 64-bit operating system. If your installed Access Database Engine is 32-bit, the 64-bit application cannot interface with it, causing the system to assume the provider is entirely unregistered.

Why does my connection test fail in Visual Studio 2022 but work when the app is running?

Visual Studio 2022 runs strictly as a 64-bit process. Its internal Server Explorer and data tools cannot load a 32-bit OLEDB provider to test the connection. However, when your C# project is explicitly compiled for x86, the running standalone application correctly loads the 32-bit provider.

Can I install both 32-bit and 64-bit Access Database Engines on the same computer?

By default, Microsoft prevents installing both 32-bit and 64-bit versions of the Access Database Engine side-by-side to prevent Office conflicts. It is possible to bypass this using the '/passive' command-line parameter during installation, but it is generally discouraged unless strictly necessary for development.