Access cannot read files that include event-driven Data Macros

Question

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.

Answer 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.