By Richard Rost 8 years ago
2021 Update: Finally broke down and got another laptop just so I could install 64-bit Office on it and start converting over my old 32-bit databases. More and more people are complaining that the old 32-bit code isn't working. So, it's on my short list of things to do starting this week. Why another laptop? Well, I've got 2 right now. One is my "server" that handles business stuff. The other is my workstation that I actually... uh... work on, including record videos. My Access database is loaded with older 32-bit code and I'm not about to take a whole day or two to undo almost 20 years of stuff at this point. So, 32-bit for my stuff. 64-bit for classes. Easier to fix ya'll first. :)
2020 Update: This article was originally written in 2013 when the default install of Office was still 32-bit. In 2018, Microsoft decided to make the default install for Office 2019 and Office 365 to be 64-bit, completely changing their previous stance on the matter. So, it's now 2020 and I'm going to be updating my databases to have a 64-bit option. I will still maintain backward compatibility for 32-bit in my lessons for the near future. I still stand by my original viewpoint: 32-bit is just fine for 99% of people and 64-bit is unnecessary, but the trend is now clear: Microsoft will be using 64-bit moving forward.
Lots of people have been emailing me asking whether or not they should install the 32-bit or 64-bit versions of Microsoft Office. Here's the general rule of thumb: Unless you absolutely need the increased capacity of the 64-bit version, then you should install the 32-bit version of Office.
The 32-bit version is the most compatible with everything else that is out there. The 64-bit version does not include compatibility with most of the ActiveX controls, 3rd-party add-ins, and ALL of the 32-bit databases that you'll find out there (including MINE).
Chances are, you probably don't need 64-bit Office anyway. The main reason for the 64-bit version is to allow file sizes over 2 GB. If your Excel spreadsheets are that big, they should be in Access! To make things worse, even 64-bit Access still has the 2 GB file size limit! If you have a single Access database file that's larger than 2 GB, you can split it up into multiple tables or upsize to SQL Server (which you probably should with that much data anyway).
Sure, 64-bit is the future... but it's a long way off. If you want to maintain any kind of compatibility with the rest of the world right now, stick with the 32-bit version. Large enterprises that are running a single solution may want to consider 64-bit, but the rest of us should just stick with 32-bit.
Even Microsoft agrees with me: "If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on earlier versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2013 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems."
How to get MY sample databases to work on 64-bit Access:
Now, I personally don't have any 64-bit installations of Office here in my office (pun intended). So all of my databases that I post are 32-bit versions. You will NOT be able to use any of the ACCDE (encrypted) test databases, but if you purchase a seminar or template, when you get the FULL version (ACCDB file) you will be able to create a new blank ACCDB file on your 64-bit machine and then IMPORT all of the objects out of my 32-bit database (tables, queries, forms, etc.). Some of my databases use 32-bit specific controls, like COMDLG32.OCX, but the majority of them should work just fine after you import the objects into a 64-bit database file.
Here's another article about the topic.
Here's an article Microsoft posted in 2018 regarding updating your VBA code: 64-bit VBA Overview.