views:

96

answers:

2

I don't believe there's a solution to my problem, but I thought I'd ask just in case I missed or misunderstood some aspect of it:

  1. I have a C# program that creates and writes to an Access Database. More specifically, a C# library that will be part of a suite of applications.
  2. This library cannot be targeted at 32 or 64 bit specifically because that would mean all the programs in the suite would have to be targeted specifically (can't load the dll into a 64 bit operating space if it's built for 32 bit, or vice versa. I think?).
  3. I believe the "2010 Office System Driver Connectivity Components" allow me to connect and write to an Access database (.mdb) from a 64 bit environment. However, one of the other requirements would be to not have an outside dependency on various Microsoft Access redistributable versions (we had issues with an Access application in the past).

Therefore, what I'm really looking for is some OS-independent (and 32/64bit independent) way to create and write to an Access database from C#. Does such a thing exist, or are my options pretty much as outlined above?

One thought was that we could pull out the dlls we depend on from the connectivity components, but I'm fairly certain those are targeted to either a 32bit or 64bit environment, so it would fail when we tried to run on the non-target platform. Or would they run like a C# program targeted to "Any" and just adjust depending on the environment?

A: 

In a prior application I worked on, there was the need to export data to an Access database. However, if Access wasn't installed, no direct way to "Create" an empty database. Since you can't connect to a database that doesn't exist, what I did was to create an empty database, embedded the file itself as a resource to the application. Then, when I needed to create a new "access database", I would stream read it, and write the empty database structure out to wherever it needed to go with whatever file name it needed. Since the database was already created in 32-bit environment, it didn't have problems for subsequent connection to it... but that too was before 64bit machines were becoming more common.

Hope this helps as an option / solution for you.

DRapp
Hello! This started out very promising, but it turns out to connect to the file, I still need some sort of database driver to be installed, and it would appear that Windows Server 2008 does not have any data access components installed by default (specifically, 64bit data access components), so I have no driver options to connect to the file. I could install data drivers, but as noted in point 3, that's not the direction we want to go (if it can be helped, but it's not looking good).
genki
DRapp, what I'd do is reference DAO 4.0 and the create the database, tables and fields as required. See the TempTables.MDB page at my website which illustrates how to use a temporary MDB in your app. http://www.granite.ab.ca/access/temptables.htm . Note that this answer doesn't help the original poster.
Tony Toews
A: 

Actually, if you write an application - you can just force-target it at 32bit and not worry at all. When started in a 64 bit environment - it will "just run".

If you're writing a dll/assembly, that will be referenced by an app, and you know that this app will be compiled as "Any CPU" or "64 bit", then you're out of luck, and this answer won't help you, probably :D

Artiom Chilaru
Please see point #2 in the original post.
genki
Oh, right.. must have misread this point >_<Afaik, the standard driver is 32 bit only.. Didn't use any other ways to use it, and if I needed to use MS access - I just forced my app to 32bit every time (
Artiom Chilaru