Side-by-Side Installs of 32-bit and 64-bit Versions of Access

We all know this can't be done, right?

You can't install 32-bit Office on a device with 64-bit Office.
You can't install 64-bit Office on a device with 32-bit Office.

Side-by-Side Installs of Different 32-bit Office Versions

In the "old days", it was common to have multiple versions of Office installed on the same machine, even if it was officially unsupported.  

Back then, the key was to make sure that you installed the oldest version first and then installed the newer versions.  If you did that, everything just worked.

As far as I know, that still works...it just got a lot more painful with Office 2007 and later.

Starting with Office/Access 2007, when you switch back and forth between different versions of installs (say 2007 and 2013), you're typically treated to a nice "Installing Office..." window as whichever version you opened goes to town overwriting a bunch of Windows Registry settings.  This struggle plays itself out over and over every time you switch versions as the two (or more) Office installs fight for Registry supremacy like two kids playing King of the Hill on top of a freshly plowed snow pile.

There used to be an Access deployment tool from SageKey Software that handled this registry rigamarole and made it so you didn't have to worry about what might be installed on your end user's computer.  

Those days are long gone.

The good news is that there are fewer differences between newer versions of Access.  The VBA version has not changed since Access 2010.  The file format has not changed since Access 2007.  The IDE has not changed since the last millennium.  In other words, if you develop an ACCDB that runs in Access 2007, that same file will run fine in 32-bit versions of Access 2019/Microsoft 365.

Side-by-Side Installs of 32-bit and 64-bit Access

Before I get to the how, let's address why you might want to do this.

There are two main situations where you would want side-by-side installs:

  • On your development computer, so that you can test your application in both 32-bit and 64-bit modes (or compile separate 32-bit and 64-bit versions, if you distribute compiled .ACCDEs...I don't)
  • On an end-user's computer, so that they can run both 32-bit-only and 64-bit-only applications

Development Computer? Use a Virtual Machine

Installing multiple versions of Office side-by-side on the same Windows installation is always a dicey proposition.

As I said above, this is not something that Microsoft officially supports.  There are all sorts of weird behaviors that could pop up.  You could even get to a point where the only way to recover is a complete reinstall of the operating system.  

That is NOT what you want on your development machine.

The solution, then, is to install a Virtual Machine (or many VMs) on your computer and install one version of Office per VM.  This may be stretching the definition of "side-by-side" install, but it's much safer than the alternative I'm going to outline below.

End-User Computer? Upgrade Your Code If You Can

Ideally, you won't need to install both bitnesses of Access on your end-user's computer.

If you update all of your Windows API calls to use PtrSafe and LongPtr–and take advantage of the #Win64 compiler constant to handle the small handful of remaining edge cases that require different code for 32 vs. 64-bit environments–then you should be able to create a single codebase that will run fine under both 32-bit and 64-bit flavors of VBA.

By far, the simplest solution is to upgrade ALL of your existing Access application so that they run under both 32-bit and 64-bit versions of VBA.

However, there still remains the possibility that you have a dependency on a 3rd-party control that is only available in a 32-bit (or 64-bit) version.  If that's the case, you'll need to make sure your end users have an Office/Access install with matching bitness.  But what happens if that same end user needs to run a second application that requires the other bitness?  

Still Stuck?  There May Be Hope Yet!

Unfortunately, installing a 32-bit Access runtime alongside a 64-bit version of Office simply DOES NOT WORK.*

What idiot wrote that with such conviction?  Me, all of five months ago.

It turns out that there is a workaround.  

At the end of this long and winding UtterAccess post, former Access MVP Albert Kallal provides a crucial bit of information, "you have to reverse the install order." Colin Riddington (aka, Isladogs) sums it up nicely:

Interestingly, when installing more than one copy of Office of the same bitness onto a workstation, I've always followed the official MS advice of installing the OLDEST version first.

BUT to install different bitnesses, the opposite seems to generally be true. Install NEWEST version first.

Colin then took things a step further, providing the results of some testing that he performed:

When You Won't Take "No" for an Answer

Installing multiple Office versions on the same computer should always be a last resort.

That said, if you find yourself in that situation, your best bet is to install a 64-bit version of Access 365 followed by a 32-bit version of Access 2013.


External references

SageKey Discontinuing Access Deployment Wizard | DEVelopers HUT
It has been announced that SageKey is discontinuing their Access Deployment Wizard thanks to Microsoft.
Windows API declarations in VBA for 64-bit
How to convert your API Declarations to 64-bit. - Common myths debunked, key factors explained!

Referenced articles

To Compile or Not to Compile
With the proper deployment infrastructure in place, distributing uncompiled Access apps can simplify your life versus compiled Access apps.
Office 2019 Runs in 64-bit Mode By Default. Here’s What That Means for VBA Developers
Through Office 2016, default installs used the 32-bit version of the software. Now that 64-bit is the default, it’s time to bite the bullet and convert your VBA code.

Photo by Mike Wolfe