This database was created with 64-bit version of Microsoft access. Please open it with 64-bit version of Microsoft access.

As my knowledge, to avoid this issues within your team, you have to replace MS Access/Office 64bit with the 32bit release.

https://msdn.microsoft.com/en-us/library/office/mt662476.aspx

When saving DB as .. you should have multiple choices of what version to save as and so on..or simply try the export option.

The answer is simple: Develop your app in 32 bit MS Access/MS Office 2016 version.

Unfortunately, Microsoft does not support different bit depth and/or different Access versions on one computer. It is easier for Microsoft but harder for clients. The export option could work but I don't think it is long term acceptable option. You should use one version across the whole company/organization.

You can't open a 64-bit file with 32-bit versions of Access.

You CAN open a 32-bit non-compiled file in 64-bit Access. This means you could open a 32-bit .accdb file in 64-bit Access, but not an .accde file.

So the answer is as others have stated - either switch your users to 64-bit, or you switch to a 32-bit development environment.

To add a few more points:

1. Starting with Office 2010, Office came in two editions; 32 and 64 bit.  The 64 bit version handles larger spreadsheets in Excel and projects in Visio, but that is it.   Microsoft to this day still recommends the 32 bit edition for the majority of users.

2. On a 64 bit OS, you can use the 32 bit or 64 bit edition of Office.

3. As you have discovered, you can't mix 32 and 64 bit.

4. When you distribute as a MDE/Accde, you have removed all source code, so it is impossible for the VBA to be re-compiled on the fly at run-time.    

5. Even if distributed as a .accdb, your app still might not run (depends on the code in it) unless you have taken steps for it to run in both 32 and 64 bit editions of Office.

Jim.

Thanks for repose.

What steps should i take so that the application run in both 32 and 64 bit editions of Office.

Thanks in advance

You should create a 32 bit application, so that will run on both platforms.

You should create a 32 bit application, so that will run on both platforms.

As both Jim and I have indicated, a compiled 32-bit app will NOT run on a 64-bit machine. You would have to distribute an uncompiled (i.e. accdb) in order for this to occur.

If you must deploy a compiled app (.accde), then you would have to maintain two versions of the application - one developed/compiled on a 32-bit of Office, and a second developed/compiled on a 64-bit installation of Office. In many cases, you can make a copy of your 32-bit app, move it to the 64-bit Office machine, and compile it in that environment.

You are right Scott, sorry for mistake.

I would like to suggest to make a script which deploy the compiled application according with MS Access platform (32/64 bit).

So, given what everyone else has mentioned, here is what you can do.

1.  give the uncompiled .accdb file to the people in your testing environment.  Then compile it into a 32 bit accde file (this may involve some changes, especially if you are using API calls).

2.  If you are using API calls, you can use conditional compilation commands to embed all of the right declarations into the application, but if you have user running both 32 and 64 bit Office, you will still need to create two compiled versions of the application when you distribute it.  I usually give them names like:

myApp_32.accde
myApp_64.accde

I don't think that 64-bit Access can save to 32-bit (and I know you can't go the other way), so I'm curious what sort of script would do this. Do you have any examples? I'd be interested to see them.

<<I don't think that 64-bit Access can save to 32-bit>>

 It cannot.

Jim.

I never said the script will use MS Access to deploy.
With a script written in Vbs, PowerShell, AD rule or whatever else scripting language you will "update" from a shared location the local compiled application.

This script can be used to check/update/run the application at every execution.

Sometimes I made mistakes....I'm human and I'm not perfect....are you?

<<Sometimes I made mistakes....I'm human and I'm not perfect....are you?>>

 Do not take offense.

  First and foremost, it is important to get good information posted.  Since there is no one that knows Access inside and out 100%, if something is said and you are not clear on it, it is best to ask.  As Scott said, he was curious.

 Also it is not always clear what someone may be talking about or trying to explain.  So again, when in doubt  you ask.

 Then as you pointed out we all make mistakes from time to time.

 Given all that, do not be surprised when someone questions something or points out a problem with something that has been said.

Jim.

Sorry, didn't mean to offend. I don't work in 64-bit Access often, so I wasn't sure if there was some way that you could compile your 64-bit Access app "down" to 32-bit.

You never said whether or not you actually have a mixed environment.  If you do, YOU have to develop in a 32 bit version and you will need to use conditional compilation commands to get around any API or VBA that is impacted.  The link posted earlier describes how to do conditional compilation.

Since 64-bit Office is incompatable with 32-bit Office, it is not possible to mix and match.  If you need 64-bit Excel because you have humongous spreadsheets, then you are stuck with 64-bit versions of the other Office components.  That means that YOU, if you need both bit versions will need to install the 32-bit version in a virtual machine so you can ensure that everything works in both environments.  Even with that, if you want to distribut as an .accde, you will need to make two of them.  One with each bit-version.  I would include the bitness in the file name.

I.E. MyAppFE_64bit.accde and MyAppFE_32bit.accde  to avoid confusion.  

You will not need to maintain two code bases if you always work in 32-bit, use conditional compilation and test the compiled file in both versions.

Just to clarify this point

<<You never said whether or not you actually have a mixed environment. If you do, YOU have to develop in a 32 bit version >>

  You don't if your using conditional compilation .  You can develop in 64 or a 32 bit environment.   The rub comes with distributing a .accde instead of a .accdb (mainly).   If you are distributing a .accdb, then your end user can use 32 or 64 bit.

 However if you are distributing as an .accde, then you must create the .accde in the correct version (use 32bit Access to create a 32 bit .accde, and 64 bit Access to create a 64 bit .accde).   With an .accde, source code gets stripped out which makes it impossible for VBA to recompile at runtime, so whatever way the .accde was created is what it's limited to.

 I think it's smart though to develop two separate editions anyway.   Whenever you rely on anything external (like ODBC drivers).    You might develop in 64 bit, hand it off to a 32 bit user (using a .accdb), and then find something doesn't work because the 32 bit version of a driver doesn't work the same as the 64 bit one.

Of course an even better course of action is to avoid the whole mess completely and just develop in 32 bit.  But that's getting harder and harder to do now.

Jim.

Why is developing in 32 bit getting harder?

If you have to support a mixed environment, you need either multiple computers, each with the proper environment OR virtual software so you can create multiple environments on the same PC.

Hardware has been 64-bit for many years and so has Windows.  The advantage of the 64-bit hardware is that the 64-bit registers provide access to larger address spaces so we can have more memory and larger disk drives.  Some software actually takes advantage of this but most doesn't.  Excel is one of those exceptions.  With a 64-bit version of Excel, you can open humongous spreadsheets (million row).  It is the ability to address larger memory spaces which makes this happen.

The downside of using 64-bit Office is the incompatibility in VBA if you've used any API code.  This is most likely to affect Access but can also affect Word and Excel.  The other downside is that if you are using add-ins, you need a 64-bit version of the add-in if you are running 64-bit office.

Given the minimal benefit of 64-bit office, MS is still recommending a 32-bit install unless you require a very large address space for Excel.

<<Why is developing in 32 bit getting harder?>>

 Because you find 64 bit more and more.  As you pointed out, you can't mix 32 and 64 bit.  Even worse, that appears to be from 2013 and up, not just within each version (I haven't tested that as yet - your actually the one that reported that).   VM's are not always a solution because they consume resources and I'm not clear on the licensing.

  So if you develop in 32 bit only, then you may not be able to support all users.

  That's what I meant; developing in 32 bit alone is getting harder to do.   I haven't gotten stuck yet, but I'm expecting to fairly soon.

Jim.