0

I use a connectionstring like "Provider=Microsoft.Jet.OLEDB.4.0;..." to open a .mdb database. Moving to a 64bit computer this does not work anymore since there is no 64 bit implementation.

My understanding is that it is done this way because Jet is deprecated. There is one workaround in which you compile your application to run as 32bit only.

What are we supposed to move to?
Is there a new provider that works in both 32 and 64 bit?

hultqvist
  • 17,451
  • 15
  • 64
  • 101
  • Jet is not deprecated, but the version you're using is not the latest version. It *is* the version that's shipped on all copies of Windows, which makes it quite convenient to use, but it's limited to 32-bit. It will work fine on 64-bit Windows, just as any 32-bit app does, because 64-bit Windows supports 32-bit apps. The latest version of Jet is the ACE, and it comes in a 64-bit version as outlined below. – David-W-Fenton Dec 19 '10 at 01:47

3 Answers3

2

Did you try this SO: 64-bit Alternative for Microsoft Jet?

Community
  • 1
  • 1
Sam B
  • 2,441
  • 2
  • 18
  • 20
  • If you read the article, you'll learn that there is no 64bit driver for Access. The ACE provider they're talking about, is 32bit as well. They suggest that you'd convert your applications to sql server or sql server compact edition. – Frederik Gheysels Dec 16 '10 at 15:52
  • @Frederik, there is no 64bit driver for Jet; but you can change it to the new 64-bit ACE driver. – Sam B Dec 16 '10 at 15:54
  • AFAIK, the ACE driver is 32 bit as well ? I just tested it by changing my connectionstring to use the ACE.OLEDB.12.0 driver, and running my app in x64 mode and got the exception: 'The Microsoft.ACE.OLEDB.12.0 driver is not registered'. When running the app in x86 mode, it works fine. – Frederik Gheysels Dec 16 '10 at 16:20
  • @Frederik, you have to download the 2010 x64 Access Database Engine (from the link provided in the target comment). I did this a few weeks ago. Unfortunately, altough it shows up in MS Download Search page, it seems to have been taken offline. – Sam B Dec 16 '10 at 16:26
  • I thought I did that as well a few months ago. :) I'll check it out later to be sure. – Frederik Gheysels Dec 16 '10 at 16:31
  • @Frederik, for sure, I will recommend a migration to SQL server for a real long-term & supported solution :). The 2010 x64 Access database Engine is (was?) provided to support data migration scenarios (from what I remember of the download page). – Sam B Dec 16 '10 at 16:34
  • The ACE version shpped with A2010 comes in a 64-bit flavor since there's for the first time a 64-bit version of Access. This is why it exists, not for compatibility with anything else or for data migration -- it's because it had to created so that 64-bit Access could be developed. – David-W-Fenton Dec 19 '10 at 01:46
1

What are we supposed to move to?

SQL Server Express 2008 R2. The move to SQL Server Expres was announced about 10 years ago.

Is there a new provider that works in both 32 and 64 bit?

Your definition of new is 10 years old :)

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • SQL Server might be a little bit overkill for some app's if Access was sufficient for those apps. :) Better to use SQL ServerCE in that case. – Frederik Gheysels Dec 16 '10 at 15:45
  • Which, though, makes even less than access did. – TomTom Dec 16 '10 at 15:47
  • Indeed. :) I have an app that runs on sql server, and needed to support a 'lightweight' desktop db as well. Eventually, I choose Access, since SqlCE had to many limitations. (Not supporting concurrent connections when the DB was on a share, was the show-stopper). – Frederik Gheysels Dec 16 '10 at 15:55
  • Well, "new" depends on the reference, in this case I had Jet in mind and then surely your suggestion qualifies as new :) – hultqvist Dec 18 '10 at 09:52
1

Change the target platform of the application to x86 instead of 'any cpu'. By doing so, your app will run under WOW64-mode on 64bit systems, and will use the 32bit Jet provider.

Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154
  • +1 for the most elegant legacy solution. I would also suggest that they move to an SQL Express implementation to prevent future problems. The author could easily make your application install and setup an SQL Express database when its installed. The author coudl also use Office 2010 which has 64-bit support as per the link thread discussed. – Security Hound Dec 16 '10 at 16:04
  • Yes this has been the workaround solution so far. The questions was more about how to move on with future projects. – hultqvist Dec 18 '10 at 09:49