I'm with Thomas, I gotten errors trying to run 32 bit access dbs with the 64 bit runtime and visa versa.

This is one of those situations where the installer can muddy the waters a bit.

The important thing to understand is that you cannot install a 32-bit Access runtime on a system that already has 64-bit Office installed, so the only compatible runtime in that situation is the 64-bit version.

What I usually recommend first is to try to isolate just the database itself. If you can get your hands on the raw ACCDB or MDB file (either from an old machine or by installing it on a system without Office already on it), then try opening that directly using the 64-bit Access runtime on the new machines.

A lot of older databases will run just fine in 64-bit if they don't rely on any 32-bit-specific API calls or external components. If that works, then great, you're done. You can just deploy it using the 64-bit runtime on your current systems, assuming they have Access with the copy of Office they got. If not, you can install the 64-bit runtime.

If it doesn't work and you start seeing compile errors, then you have two choices:

1. Update the VBA for 64-bit compatibility (PtrSafe declarations, LongPtr, etc.). I've got videos on that process, but that's usually the fix when code is the issue. If it's just code (and not 32-bit specific external objects) then you should be fine.

2. If you can't modify the database or don't want to go down that road, then the other option is to match the original environment. That means uninstalling 64-bit Office on the new machines and installing the 32-bit version instead, which will allow you to use the original installer and runtime as-is. Not my option of choice, but it's actually the path of least resistance if updating the Access db is going to be a pain.

So in short: test the database by itself first, fix the code if needed, and only fall back to 32-bit Office if you absolutely have to.

Richard I think I read in some other guru forum (from across the pond), that a 32-bit runtime can be installed on a 64-bit system with 64-bit Office installed. I don't recall all the particulars, like how to tell which bit program to use, I'm guessing a shortcut on the desktop would get it to the correct .exe if properly setup. Does that sound correct?

Come to think of it, I haven't seen away to select which Office products & features to install, like we were able to do with the old CD installs. Does that still exist somewhere? Maybe uninstall only the 64-bit Access and install the 32-bit runtime?

I think, in the long run, following Richard's goal of trying to nudge everything into working on 64-bit when possible, especially for a database you plan to continue developing and working on moving forward, or that you just need to ensure will continue to work as indefinitely as possible.

I did read This Article by Mike Wolfe some time ago and briefly played around with installing different environments. It works, and I use that term loosely, but I can understand why it's not something that not publicly listed on Microsoft's web site as newer users could very easily end up causing themselves more problems than they start with.

For my own purposes, my first choice is always to try to bring the old system into modern Access, but it's nice to know that with a little stress, it is possible in many cases to create a dual environment.

Yeah, I've seen that article and a few others like it. The short answer is: yes, it can be made to work in some cases, but it's definitely not something I'd recommend as a standard approach.

Mixing 32-bit and 64-bit Office/Access on the same machine isn't officially supported by Microsoft, and even when people get it working, it tends to be fragile. You can run into all kinds of odd behavior, especially with installs stepping on each other's registry settings. It's one of those "works until it doesn't" situations.

There are some tricks, like installing the newer 64-bit version first and then layering the older 32-bit version on top, but even then it's more of a workaround than a real solution. Fine for experimenting or a one-off scenario, but not something I'd want to rely on in production or for end users.

In most cases, you're still better off doing exactly what we talked about earlier: either update the database so it runs cleanly in 64-bit, or match the environment (go all 32-bit if you have to). Or, if you really need both for testing, use a VM and keep them separate.

So yeah, possible? Sure. Ideal? Not even a little.