browser application and MS Access

[Robdemanc]

Hi. I have a specific question. My situation is like this: A few weeks back I managed to get my VB.net express 2010 connected with Access 2010 using Microsoft.ACE.OLEDB.12.0, to do this I had to change the configuration manager to target platform '64x' instead of 'any cpu' (if i dont do this the database will not connect). This works well for normal windows apps and I produced a front end for my DB. I was then able to produce a WPF project for the same DB. However, now I try to create a WPF Browser application I cannot have my platform target '64x', it complains and tells me to set it to 'any cpu' or not set it at all. But when I do this and try to get the browser app to run I get an error: "Microsoft.ACE.OLEDB.12.0 is not installed on local machine."

My question is: Am I wasting my time with Access for the browser app? It seems people think access is no good for the web. I would like to get the app on the web and connect with access but I know there are issues with 64bit apps. I have the correct driver for access so I am wondering if it just doesn't work for WPF Browser Applications.

Thanks for any help or info.

 

[Dunfiddlin]

Download: 2007 Office System Driver: Data Connectivity Components - Microsoft Download Center - Download Details

A compatibility issue which is now (in)famous!

 

[jmcilhinney]

Download: 2007 Office System Driver: Data Connectivity Components - Microsoft Download Center - Download Details

A compatibility issue which is now (in)famous!

That is quite probably not the answer. If the user already has Microsoft Office already installed then ACE is already installed, so installing ACE will not help. When you deploy the app, the user will need to install ACE if they do not already have it or Microsoft Office installed.

The original post is wrong too. You did not have to change your app to target 64x. There is no such platform. The choices are:

x86: the app will run in 32-bit mode on all systems.
x64: the app will not run on 32-bit systems and will run in 64-bit mode on 64-bit systems.
Any CPU: the app will run in 32-bit mode on 32-bit systems and in 64-bit mode on 64-bit systems.

If you want to use the Jet or ACE OLE DB providers then you pretty much always have to target x86. Jet is only available in a 32-bit version. ACE is available in both 32-bit and, as of Office 2010, 64-bit versions but they cannot both be installed on the same system. It will be rare to find 64-bit Office or ACE installed so it is safest to go with 32-bit only.

So, the solution to your issue is to set the target platform of your app to x86 and make 32-bit Office or ACE a prerequisite for running your app.

 

[Robdemanc]

The original post is wrong too. You did not have to change your app to target 64x. There is no such platform. The choices are:

x86: the app will run in 32-bit mode on all systems.
x64: the app will not run on 32-bit systems and will run in 64-bit mode on 64-bit systems.
Any CPU: the app will run in 32-bit mode on 32-bit systems and in 64-bit mode on 64-bit systems.

If you want to use the Jet or ACE OLE DB providers then you pretty much always have to target x86. Jet is only available in a 32-bit version. ACE is available in both 32-bit and, as of Office 2010, 64-bit versions but they cannot both be installed on the same system. It will be rare to find 64-bit Office or ACE installed so it is safest to go with 32-bit only.

So, the solution to your issue is to set the target platform of your app to x86 and make 32-bit Office or ACE a prerequisite for running your app.

I suppose I am a bit confused then. I have 64bit office and 64bit vb.net express, it will only run with ACE if I choose target x64, not x86 or any cpu.

My solution was to change the db to SqlServer and it connected fine through the browser. But I would like to achieve this with Access if possible. But I swear it will not connect to the db for x86 or any cpu, only x64.

Thanks for the help though.

 

[jmcilhinney]

There is no such thing as 64-bit VB Express. Visual Studio is a 32-bit app but it can compile projects to both 32-bit and 64-bit apps.

If you have installed 64-bit Office then my previous post wasn't quite correct. The thing is, it was probably a mistake for you to do so. There are only a couple of things that 64-bit Office can do that 32-bit Office can't, most notably it supports huge Excel sheets. Microsoft itself recommends that only those users who specifically need 64-bit Office install it and everyone else install the 32-bit version for maximum compatibility, most notably for existing COM add-ins, which are universally 32-bit.

Your main issue is that almost all your users will have 32-bit Office or ACE installed unless they are all in an specific environment that mandates 64-bit Office. It is actually impossible to support all possible combinations of Windows OS and Office with just one build of your project. Any CPU will support 32-bit Office on 32-bit Windows and 64-bit Office on 64-bit Windows, but it will not support 32-bit Office on 64-bit Windows, which is the most common configuration on Windows 7. x64 (NOT 64x, which doesn't mean anything) will support 64-bit Office on 64-bit Windows, which is the least common configuration. x86 will support 32-bit Office on 32-bit Windows, which is still very common, especially on Windows XP, and 32-bit Office on 64-bit Windows.

If you want maximum compatibility in one build then you should uninstall 64-bit Office on your own machine and install 32-bit Office and then set your target platform to x86. If you want total compatibility then you will need to build your project twice: once targeting x64, for those with 64-bit Office on 64-bit Windows, and once targeting x86, for everyone else. The good thing is that there's actually no need to switch back and forth. You can develop your app using just the one target platform, whichever suits your environment. When you are ready to release, you build once as normal and then you change the target platform and build again. You can then switch back and continue developing with one target platform. You only need to build twice when it's time to release.

Having said all that, if you have 64-bit Office installed, I'm not quite sure why targeting Any CPU didn't work. Any CPU means run in 64-bit mode on 64-bit machines so it should have been able to find the 64-bit ACE OLE DB provider. Not sure what's up with that.

 

[Robdemanc]

Thanks Jmc, all that info has helped clear up my thoughts. I have it working with SQLServer now and may stick with that so I won't have need for Office.

 

[JuggaloBrotha]

Just to throw in my 2 cents. Because you can't have ACE x86 and ACE x64 installed on the same system at the same time, when it comes to Access databases I use Access 2010 to create Access 2003 databases (*.mdb files, not *.accdb) then in .Net I use the JET driver to connect to it (JET is x86 only, so all of those apps I set them to compile to x86 Only).

The end result is that it doesn't matter what version of Windows the end user has, it doesn't matter if it's x86 or x64 windows, my app runs in 32-Bit only and uses the 32-Bit JET to talk to the database.

 

[Robdemanc]

Just to throw in my 2 cents. Because you can't have ACE x86 and ACE x64 installed on the same system at the same time, when it comes to Access databases I use Access 2010 to create Access 2003 databases (*.mdb files, not *.accdb) then in .Net I use the JET driver to connect to it (JET is x86 only, so all of those apps I set them to compile to x86 Only).

The end result is that it doesn't matter what version of Windows the end user has, it doesn't matter if it's x86 or x64 windows, my app runs in 32-Bit only and uses the 32-Bit JET to talk to the database.

I tried out your suggestion, but my Access 2010 will not save the database with calculated columns, or related columns in a 2003 format. I am going to stick with SQL Server, it seems better for what I am doing.