Access x32 vs x64 Compatibility

A more and more common question in Access, and Office forums in general, relates to using Access x32 (32 bit) vs using Access x64 (64 bit).  How they play together … etc.

Now some people erroneously believe that since their machine is running a 64 bit version of Windows that Office is automatically 64 bit as well, or that they must install the 64 bit version. This is not the case.  Microsoft themselves recommend installing the 32 bit version.

“We recommend the 32-bit version of Office for most users, because it’s more compatible with most other applications, especially third-party add-ins.” — Microsoft, see: 64-bit editions of Office 2013

Personally, I see no benefit to installing the 64 bit version of Office/Access beyond Excel and Word being able to handle more data, but if you are requiring that to begin with, Excel/Word are the wrong tools! (but that’s entirely another discussion altogether).

Nevertheless, more and more people are using 64 bit versions of Office and Access and questions about compatibility abound, so I thought I’d try to explain some of the basics in plain English and try to centralize little bits of information scattered here and there into one simple to digest article.
 

The General Rule

accdb

As a general rule, a database (in accdb file format) developed on Access x32 should run fine on Access x64 and vice versa.

When the General Rule Goes Awry

Although, a database made on Access x32 should run fine on Access x64 (and vice versa), some people report issues. You have 2 options:

  • Create a new blank database in the target bitness and import everything
  • Decompile the original database and migrate it to the other bitness and then recompile it

 

The Exceptions to the Rule

accde

Compiled versions (accde file format) must be compiled on the same version of the application they will be run on. So an:

  • x32 accde must be compiled and run on Access/Office x32
  • x64 accde must be compiled and run on Access/Office x64

So in other words:

  • To create an accde compatible with 64-bit installations of Access, you must use Access 64-bit to create it.
  • To create an accde compatible with 32-bit installations of Access, you must use Access 32-bit to create it.

So if you need to support both 32 and 64-bit versions of an accde, you need 2 both versions of Access yourself to be able to create the accde files.

APIs

You will need to review all of you API calls providing conditional compilation directives containing modified API declaration that are compatible with both x32 and x64.

I briefly explain how this is done in my article VBA – Early Binding and Late Binding – Part 2 and provide an example for the well known fOSUserName() function used to determine the current user’s login username.

The original x32 API Declaration is

    Private Declare Function apiGetUserName Lib "advapi32.dll" Alias _
            "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long

but now, you’d need to add the x64 version of the same API Declaration and use Conditonal Compiler Directives so the application uses the appropriate Declaration based on the bitness of the application running the database.  As such, the API declaration would become

#If VBA7 And Win64 Then
    'x64 Declarations
    Private Declare PtrSafe Function apiGetUserName Lib "advapi32.dll" Alias _
            "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
#Else
    'x32 Declaration
    Private Declare Function apiGetUserName Lib "advapi32.dll" Alias _
            "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
#End If

and you must do this for all your APIs and then adjust your code for any changes in the variable types.

An EXCELLENT resource for 64-bit API declarations can be found at:

Download Office 2010 Help Files: Win32API_PtrSafe with 64-bit Support from Official Microsoft Download Center
Windows API Declarations and Constants for Visual Basic (Updated for the 64-bit version of Microsoft Office 2010) provides declarations for Microsoft Visual Basic programmers who want to call Windows API routines. This file is updated to include calls to the 64-bit version of Microsoft Office 2010.

Do note however, that I have found mistakes in Microsoft document, error is some declarations, but it is still one of the best, if not the best resources available on the subject. Don’t get me wrong, it is probably 95% accurate, but I did manage to fall on 2 declarations so far that were incorrect and wasted a lot of time because I assumed MS would make mistakes!

ActiveX Controls

“ActiveX controls and COM add-ins that were written for 32-bit Office won’t work in a 64-bit process”

And what is worse is the fact that in many cases, it is not possible to find the x64 version of x32 ActiveX Controls.

Yet one more reason never to use ActiveX controls in the first place!!!
 

Office Automation Headaches

“x64 of Access cannot automate say Outlook 2007 or ANY previous version of Word. In other words, you cannot mix and max the “bit size” of applications. So if you deploy the Access x64 runtime on a machine with any previous version of office, you not be able to automate Word, Excel, Outlook etc.” — Albert Kallal, see: Anyone have EXPERIENCE in converting 32 bit Access to 64 bit?

 

Installing Both x32 and x64 Versions of Office on the Same Computer

The short answer is this is simply not possible.

“many parts of office such as a spell checker, VBA code editor, and ribbon etc are shared components, the windows installing system and the office installer will NOT allow you to install mixed versions of ANY part of the SAME edition of office. In other words you can not install a 32 bit version of word 2010, and a 64 bit version of access 2010 or Excel 2010 on the same machine.” — Albert Kallal, see: 32bit Access vs 64bit Access, Office 2010

In the case of MS Access, this applies to both Access and Access Runtime.

What is possible however is to install different version with different bitnesses. So you could in fact install MS Access 2010 x64 along side of MS Access 2013 x32.
 

Copying Objects Between Projects of Different Bitnesses

The good news is there is no issue copying Access database objects between databases of different bitnesses, but the above listed exceptions still apply so you need to review the VBA code, ActiveX controls.
 

Summary

The best thing you can do is stick with Office/Access x32.

That said, if you are going to need to support both x32 and x64 databases, then you will need 2 PCs or 2 virtual machines so you can have an installation for each bitnesses to be in a position to compile your databases.  Furthermore, avoid the use of ActiveX controls and add conditional compilation directives so you can have the appropriate API declarations for each bitness and remain backwards compatible.
 

Resources

4 responses on “Access x32 vs x64 Compatibility”

  1. Philipp

    Good post! There is still not enough good information about this topic out there.
    Just a side note: Your 64-bit declaration of GetUserNameA is not correct. The nSize argument has still to be a Long in x64, not a LongPtr.

  2. Argy Bargy

    I have tried to ‘dual-compile’ an Access database for 32-bit and 64 bit but, it doesn’t work for me.
    With conditional compile statements around my DECLARations, I get one of two responses, depending on the machine doing the work:
    In Windows 7, I see no errors, and it can be published, but the MDE file refuses to run in Windows 10;
    In Windows 10, the 32-bit code appears as erroneous (red text). It can be published to 64-bit but, will not run in Windows 7.

    Any surefire solution is appreciated. An example of my failing code is given:

    #If Win64 = 1 And VBA7 = 1 Then
    Private Declare PtrSafe Function GetUserName Lib “advapi32.dll” Alias “GetUserNameA” (ByVal lpBuffer As String, nSize As Long) As Long
    #Else
    Private Declare Function GetUserName Lib “advapi32.dll” Alias “GetUserNameA” (ByVal lpBuffer As String, nSize As Long) As Long
    #End If