ERROR - The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.
I support a .NET application which reads a version table in its background database, which is Microsoft Access. If the version is wrong, the application refuses to run. Recently, one of the application users upgraded to a 64-bit machine, and the application began reporting that the backend database was "the wrong version", even though it was in fact the same database that had worked fine on a 32-bit machine. After some debugging, I unearthed the following error message (which was being swallowed): ERROR - The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.
Thanks to Google and other bloggers, I learned that Visual Studio 2010 Professional compiles, by default, with an option called "Any CPU". But after recompiling the application with the "x86" option (which is an alternative to "Any CPU"), the application began to work on either a 32-bit or 64-bit CPU. Huh?
Apparently, with the "Any CPU" option, .NET ran the application as 64-bit (because it happened to reside on a 64-bit machine at the time) and a mismatch occurred when it tried to read from the 32-bit Access database. By forcing the compiler to be "x86", I forced the program to run as a 32-bit process even though it resides on a 64-bit machine, and no mismatch occurred.
I did notice that the application starts a bit more slowly than it did on a 32-bit machine, but once running, it warms up and runs just fine.
Those compiler options are very poorly named. And now when Office upgrades, someday, to 64-bits, I'll probably have to recompile again. Thanks, Microsoft.
Thanks to Google and other bloggers, I learned that Visual Studio 2010 Professional compiles, by default, with an option called "Any CPU". But after recompiling the application with the "x86" option (which is an alternative to "Any CPU"), the application began to work on either a 32-bit or 64-bit CPU. Huh?
Apparently, with the "Any CPU" option, .NET ran the application as 64-bit (because it happened to reside on a 64-bit machine at the time) and a mismatch occurred when it tried to read from the 32-bit Access database. By forcing the compiler to be "x86", I forced the program to run as a 32-bit process even though it resides on a 64-bit machine, and no mismatch occurred.
I did notice that the application starts a bit more slowly than it did on a 32-bit machine, but once running, it warms up and runs just fine.
Those compiler options are very poorly named. And now when Office upgrades, someday, to 64-bits, I'll probably have to recompile again. Thanks, Microsoft.
1 Comments:
Interesting.... nice catch on that one. As with any change in the IT world, the move to 64-bit is likely to be fraught with very special, annoying cases like these unfortunately
By Eric G, at 8:22 PM
Post a Comment
<< Home