64-Bit Access

Richard You're right - if you built the database in 64-bit Access and want to run it in 32-bit, you're going to need to uninstall your 64-bit version of Office and reinstall the 32-bit version. There's no way around that part, unfortunately. Microsoft doesn't let you have both installed at the same time.

As for the database itself, yes, you should be able to import all your tables, forms, queries, macros, and reports into a new 32-bit database with no problem. Those objects are platform-neutral.

Where you'll likely run into issues is with VBA code. If you've got any API declarations or code that specifically targets 64-bit systems using PtrSafe or LongPtr, you're going to have to modify that to be compatible with 32-bit. The good news is that going from 64-bit to 32-bit is usually easier than the other way around - most of the changes you made to support 64-bit just need to be stripped out or adjusted.

I'll be honest - I've never had to go backward like this myself. I've always gone from 32 to 64. But give it a shot, see how it goes, and post here if you run into any trouble. We'll try to help. That said, I'm not reinstalling 32-bit Access just to test this, so you're kind of the trailblazer here, lol.

Let us know how it turns out.

Thanks Alex and Rich! I figure, to do this I'll use a laptop that as far as I know only has the 64 bit Runtime on it. I can take that off and re-install my stand-alone Access which I hope gives me the option to install as 32-bit, I can't remember.

Regarding those 64-bit API's would the debugger catch those?

Thanks! - Rich

Yeah, I'm pretty sure if you have a 32-bit version of Access installed and you're trying to run 64-bit code, if you do a debug compile, it should catch it. But it's been a long time, but I think if I remember, it'll show up, it'll even just show up red in the code editor because the 32-bit version doesn't understand the 64-bit code.

Thanks Rich!

I've got some confusion regarding this conversion back to 32-bit. It's a split database and I haven't tried it yet, but what to do about the tables? Do I import them as well? And the data file, I'm assuming that needs to be converted to 32-bit too? Thanks!

You should still import everything into new database files. If you just change the front-end, it should still be able to connect to the linked tables in the back-end, regardless of the bitness of that file. But I'm not a hundred percent sure. I don't think I've ever tried it, but just to be safe, I would do both of them.

Thanks, Rich. I did as you said, and it seems to be working, but I think I took unnecessary steps. Just remember, I'm trying to duplicate the two files of a split 64-bit database into a split 32-bit database.

So to start, I created two blank database files. My Access on the laptop is 32-bit, and I double-checked, it is running in 32 bit. It's on my laptop, too, and I find working from laptops about the hardest thing to do.

So I set to copy the front-end file into the first 32-bit database and everything imported successfully, though there was no data in the tables. That we expected to happen, or so I thought, since the front of the 64 bit front-end are linked.

I then set to copy the back-end file into the second 32-bit database, while not much to do since only the tables are in it. And they imported successfully.

Then to link the front end with the back end, I imported this time from the 32-bit back-end to the 32-bit front-end. And that worked, except now I had two sets of tables in the front-end. I used the external data/link form to do this. When I was finished I now had a duplicate of each table, one with data and one without, and a 1 at the end of each table name that was imported/linked.

I figured I screwed up somewhere and deleted all the tables with no data, and then renamed the remaining tables to match what they should've been (deleted the 1 in other words).

I'm going to save the 'issues' to another posting because myself and laptop are not the best of friends. That and I've been up all night long though not doing 'just' this.

Rich

Yeah, think of this as one of those tasks that once you do it, you don't have to do it anymore. LOL.

In the event this is an unknown:
Microsoft Access 2024 supports both 32-bit and 64-bit environments, but there are important nuances to keep in mind I was told. I put them at the end
I am just now transitioning so I do not know all variables to this

But firstly . .
- Access database files (e.g., .accdb, .mdb) are platform-independent, meaning they can be opened in either 32-bit or 64-bit versions of Access.
- However, compiled files (like .accde or .mde ) MUST match the bitness of the Access version they were created in. A 32-bit .accde won't run in 64-bit Access unless recompiled. This can be done by opening the 32 bit in a 64 bit environment, saving as 64 bit .accdb and then saving as 64 bit .accde. AS LONG AS you have not used Declare or Long.
- I think there is also a VB code that can be inserted as a standard module to accommodate 32Bit to 64 or vice versa.

In 32-bit Access:
You can still use Declare statements without PtrSafe, and it should work fine. If you include PtrSafe, it shouldn't cause errors—it’s just ignored by the 32-bit compiler. This makes your code forward-compatible with 64-bit Access, which is helpful if you plan to distribute your database to users with different Office versions.
✅For thought: Use Declare PtrSafe along with LongPtr data types if you want your code to run seamlessly on both 32-bit and 64-bit Office installations.

Nuances:
-  VBA code and API declarations may need updating for 64-bit compatibility. For example, Declare statements should use PtrSafe and LongPtr to avoid errors like Richard stated. And Debug Compile does catch it as it is seen as a foreign language lol ("because the 32-bit version doesn't understand the 64-bit code.")
- ActiveX controls and third-party add-ins must be compatible with the installed version. Some legacy 32-bit controls won’t work in 64-bit Access
I am just now getting office 2024, so not sure of all the variables.

Alex YES! Thats the code lol :) Thank you!