3

My question is based from here : Unrecognized database format to other PC

On the link above, I was struggling on why my database application doesn't work with other pc with the fact that the first app that I made is working fine.
Now, I've narrowed it down to the point where the problem is the database itself.
I am developing in a 32bit Win7 OS with Access 2010 compiling to Access 2007 format.
And so, I used Gord Thompson's code in here Automatically renumber records in an Access table after data changes have been made (Macros, when I add that, that's where the problem begins)

Of course its working on my computer.. But then it got an error in other pc, about threading. It changed when I installed an access database engine. Now the error is Microsoft 12.0 Provider blah blah..
So I was missing a driver? I tried..

  • AccessDatabaseEngine2007
  • AccessDatabaseEngine2010 32
  • AccessDatabaseEngine2010 64

NOTE (Build Config x64)

  • 64bit ~ First one,(this pc doesn't have access installed, but working) After installing each, it has worked on a 64bit PC..

  • 64bit ~ Next one, I forced install the third engine to a 64bit PC because its MS office is 32bit using thison cmd $> AccessDatabaseEngine_X64.exe /passive. Now its working on the 2nd 64bit PC.

  • 64bit ~ On the third one, no matter what I do. Its not working. Still unrecognized, then 12.0 driver is missing even though I installed 4 types of DB engine twice. Although the force installation does not work in that particular PC, I wonder why.

UPDATE

  • 32bit ~ The fourth one, in which this app will be used, AnyCpu compiled said "unrecognized database format" same as x86, and x64 doesn't run. After I installed AccessDatabaseEngine.exe - 2007, still same result

What should I do to make my application be accepted by any pc?
- Make a 32 and 64 bit version
- Build using AnyCpu / x64 / x86 Yes I have done that, but both are not working on the last pc.

Any suggestions? I can remake my app, my database, its okay as long as it will work for other pcs, but I just literally did that, nothing new.

Community
  • 1
  • 1
AdorableVB
  • 1,383
  • 1
  • 13
  • 44

2 Answers2

1

Personally, I wouldn't invest a great deal of time trying to troubleshoot inconsistent behaviour when the second "N-bit" version of the Access Database Engine ("ACE") install is forced via the /passive switch. We must assume that the ACE development team had their reasons for writing the installer in such a way that the normal behaviour is to prevent both 32-bit and 64-bit versions of ACE from existing on the same machine.

As for deploying your application so that it will run on "any" machine, you must first accept the requirements that

  1. the target machine must have at least the Access 2010 version of ACE installed, and
  2. your application must be running in the same N-bit environment as the installed version of ACE.

One possible approach to address point #2 would be to build two versions of your application, one targeting just 32-bit and the other targeting just 64-bit. The 32-bit version would be the one that the user actually launches (i.e., the one that has a shortcut created for it in the Windows "Programs" list). It could then do something like this:

  • Try connecting to the database. If it succeeds, then just continue running (as 32-bit).
  • If the connection fails then try to start a copy of the 64-bit version of your application.
Gord Thompson
  • 116,920
  • 32
  • 215
  • 418
  • On your point 1, is this what you mean? http://www.microsoft.com/en-us/download/details.aspx?id=13255 - 2010 Redistributable version. In your point 2, am I going to base it on the "*N-bit OS*" or the "*N-bit Office*"? – AdorableVB Feb 28 '14 at 00:57
  • ^ Please add the link I have provided above. Its the redistributable version, in which I learned from http://blog.codefluententities.com/2011/01/20/microsoft-access-database-engine-2010-redistributable/ I installed 32 to 32bit OS and 64 to 64bit OS. The thing why I can't install using Admin CMD is that it cannot run on system32 folder, I changed it, then tried to install again. It worked fine on the third PC with both anyCpu & x64 build config. Now I am pretty sure that it will also work in the last PC. thanks – AdorableVB Feb 28 '14 at 05:27
0

Set the compile option to AnyCPU under Build,Configuration Manager, Active Solution Platform.

If you using Express version see this post

Community
  • 1
  • 1
Trevor
  • 7,777
  • 6
  • 31
  • 50
  • I have done that, and as I have stated, the x64 compilation works, but not in all pcs. – AdorableVB Feb 27 '14 at 05:13
  • NO NO NO!. You cannot automate an x32 program with x64. You MUST match the bit size. The office code includes the Ribbon, VBA, Excel code, and a MASSIVE HUGE LIBRARY of SHARED code. When you create an instance of a COM object (one of the gazillions of those bits and parts that make up the office install) are you going to get a 32 or 64 bit instance of that object? You cannot have two versions of the same COM object registered. Each office object is HUGE dependent on ZILLION other objects. The .net code MUST be compiled to the vision of office installed else .net launches as x64 on a x64 box. – Albert D. Kallal Feb 28 '14 at 16:15