I have WinXP x64. Trying to work with OleDb but the errors "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine." popup.

I have Msjet40.dll in C:\WINDOWS\SysWOW64 and
wmsjet40.dll in C:\WINDOWS\ServicePackFiles\i386

ver 4.0.9505.0

Do you have an idea how to register it?

Hi Lucky:

The behavior you described is expected. If your application runs in 64-bit mode, all of the components it uses must also be 64-bit. There is no 64-bit Jet OLE DB Provider, so you get the message described. You would receive a similar error when trying to connect to a database using OLE DB or ODBC if there is no 64-bit version of the specified OLE DB provider or ODBC driver.

This problem only occurs in applications that run in 64-bit mode. Compiling the application so it runs only in 32-bit mode is the best current solution.

For more details, please visit Win XP X64 Jet V4.0.

Thanks!

Hi Lucky:

The behavior you described is expected. If your application runs in 64-bit mode, all of the components it uses must also be 64-bit. There is no 64-bit Jet OLE DB Provider, so you get the message described. You would receive a similar error when trying to connect to a database using OLE DB or ODBC if there is no 64-bit version of the specified OLE DB provider or ODBC driver.

This problem only occurs in applications that run in 64-bit mode. Compiling the application so it runs only in 32-bit mode is the best current solution.

For more details, please visit Win XP X64 Jet V4.0.

Thanks!

Hi,

Does this workaround work with Asp.net Applications also?

greats from Austria
Andy

I'm trying to run an ADO.NET SDK sample that uses MS Jet 4.0. Does it mean there is no work around if I'm using Visual C# 2008 Express running on Vista 64-bit OS? The only project configuration is for AnyCPU and changing this as I understand is disabled in the Express version. At this point I don't have the luxury to re-install my OS.

Thanks.

-TK

Feng Cheng -

I appreciate your post on this issue, but I would strongly disagree that the behavior is expected and it should be elevated to a resolution.

If someone dug a hole outside my front door overnight and I fell into it the next day, the fact that I fell into it would not be expected. It would be unexpected.

I expect when a company posts a new product like C# Express Edition 2008 and tries to encourage the world to use it, they would enable it to work with their own Access 2007 database product on the hardware most developers are using to run both applications.

The failure to provide that basic support makes educators like me give up trying to teach students to use Microsoft products as those students will, like me, waste too many valuable educational hours tracking down unexpected "expected behavior".

The only expected behavior relevant here is the migration of long term customers like myself to other applications.

Is there anyway a C# Express Edition 2008 application can connect to an Access 2007 database on a 64-bit Vista system?

NoNewTricks,

I am wrestling with the same issue too, and I understand it is a pain. However, it is expected. The Jet database platform, on which Access is built, has been deprecated for a number of years. Microsoft recommends choosing a different database platform for many kinds of tasks. Microsoft also provide free (as in beer) database platforms: SQL Server Express and SQL Server CE.

Keep in mind that Microsoft continues to provide basic support for the Jet database platform. Microsoft does not provide the particular advanced support you are looking for, namely, 64-bit OleDb support.

Microsoft is sending mixed messages, which sum up as: stop using Jet; however, continue building Access-centric applications if it makes sense for your business (but stop building database applications with an Access database backend).

I've been having the same issue, and I just solved it!

I just got a new computer and it has 64 bit Vista, and my C# application can no longer talk to my Microsoft Access database because the 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.

(By the way, isn't Vista supposed to suck? Because I'm using it and so far I freakin' love it.)

This is a Winforms app, not a Web app. If you're building a Web app there appears to be an easy solution where you change a setting in IIS. As for Winforms, if you have Visual Studio it appears you can solve the problem by setting the target cpu to 32 bit. I've also seen a solution where somebody puts their data access layer in a separate DLL and calls it as a COM+ object. Those are the solutions I've found by Googling.

BUT this doesn't help me because I'm using Visual C# Express, which doesn't have the option to change the target CPU.

Tonight, I finally figured out a solution. Ready for this?

Don't use Visual C# Express!

Go download SharpDevelop, another free .NET development environment, which you can get here:
http://www.sharpdevelop.net/OpenSource/SD/Default.aspx

Find the following setting:

Project -> Project Options -> Compiling -> Target CPU (not Platform)

Change this setting to "32-bit Intel-compatible processor".

SharpDevelop is quite cool. I think I still prefer Visual C# Express for day-to-day coding, but it's nice to keep SharpDevelop around for these sorts of situations.

(Since it appears SharpDevelop can open Visual Studio solutions, there's no reason you couldn't code in one program and then build in the other.)

Hope this helps! Good luck!

(p.s. - when this problem first arose I thought I was out of luck and so I decided to change my database backend from Microsoft Access to MySQL. Now I've found a solution to the original problem, but I think I may keep MySQL for my application anyways! It opens up new possibilities for my application, and guarantees a longer life.)

Through some googling, I've found a workaround for this "feature" using Visual C# Express.

1. Close your project.
2. Open up your [projectName].csproj file in your text editor of choice
3. Scroll until you find the following chunk of XML:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>TRACE;DEBUG</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

4. Above the last line, add the following line:

<PlatformTarget>x86</PlatformTarget>

5. Now scroll down to the next block, which should be directly below it and look something like this:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

6. Now simply do the same thing you did in the other block, adding the line below:

<PlatformTarget>x86</PlatformTarget>

7. Everything should work next time you open your project.

This process has made projects that use jet to get to Access work properly for me under Vista x64 Ultimate.

Microsoft should really get on fixing this, especially since it's as easy as enabling an option on the config menu for Express. Things like this are a huge turn-off for student developers like myself to their platform. As soon as this cropped up, I started wishing I had chosen Java or Python for my project.

I was also struggling with this issue. Thanks for your help.
Editing the project file has solved the issue. Now I can use Jet 4.0 on 64 bit Vista

Thank you.

which correction steps should I follow if I'm running into this error message on my webdev running x64 2003 server OS?

Dear All,

i'am using Windows 2003 Server 64 bit Edition,
same with cajunzx6's problem

Please give me advices?

Thanks,

Thank you, Matt! You save me :)