Link to home
Create AccountLog in
Avatar of WORKS2020
WORKS2020Flag for United States of America

asked on

32 vs 64 bit versions of Access, how to convert

I have clients using Office 2013, 2010, and 2007. Everyone on MS Office 2013 is 64 bit, some users on 2007 are 32. Clients received a MS Access 2007 database they need to open which is 32 bit. When they try to open in MS Office 2013 (64) it immediately fails warning the 32 bit is not compatible.

Anyone know a way to convert a 32 bit MS Access 2007 to 64 MS Office 2013?
Avatar of Joe Howard
Joe Howard
Flag of United States of America image

The only two issues (as far as I know) are ocx controls and api calls.

If your application uses 32 bit ocx's you will have to replace them with the 64 bit version (if they exist, if not you're out of luck).

As far as the api calls are concerned, you can use what's called conditional compiling which will enable using the same code on both 32 and 64 bit machines. Here is a sample:
#If Win64 then
' 64 bit api calls

' 32 bit api calls

#End If

Open in new window

Avatar of WORKS2020


thanks macro shadow, I can't install the product sorry I mentioned they can't open, I meant to say I can't install.
MacroShadow has the gist of it right
There are new keywords and datatypes that must be used in 64 bit API calls

There is the PtrSafe keyword that needs to be employed, and LongPtr and LongLong data types.
You can walk through the VBA code base and alter the code as suggested in the articles.

You cannot use 32-bit ActiveX controls.
This may be the biggest PITA
Native 64-bit processes in Office 2010 cannot load 32-bit binaries. This includes the common controls of MSComCtl (TabStrip, Toolbar, StatusBar, ProgressBar, TreeView, ListViews, ImageList, Slider, ImageComboBox) and the controls of MSComCt2 (Animation, UpDown, MonthView, DateTimePicker, FlatScrollBar).These controls were installed by previous versions of Microsoft Office and are installed by 32-bit Office 2010. An alternative must be found for existing Microsoft Office VBA solutions that utilize these controls when the code is migrated to 64-bit Office 2010. 64-bit Office 2010 does not provide 64-bit versions of the Common Controls.
Your best option is to not use 64 bit if possible.  Microsoft is still recommending the 32 bit edition for most users as there are limited 3rd party controls for 64 bit, and few advantages.

If your distributing the app as a MDE/ACCDE, then you'll need to maintain two version no matter what.  As far as what needs to be changed, as MacroShadow said, any OCX controls, references to 32 bit libs, and API calls.

Here's some info to help with that:

This will help you determine what might need to be changed:

Microsoft Office Code Compatibility Inspector user's guide

also read:

 Compatibility Between the 32-bit and 64-bit Versions of Office 2010

and the section "Introducing the VBA 7 Code Base" for the general overview.

All the new 64 bit calls are here:

a list of all the calls that were modified for 64 bit:

Last, in the 64 bit edition of Office, all calls need to be 64 bit, which means any ODBC drivers you use must be 64 bit as well.

Again, it's best to stay away from the 64 bit edition if you can avoid it.

I can't install the product
I don't understand which product can't you install?
The other issue is with distributing an .accde.  Since the .accde is compiled, it MUST be produced by the correct bit-wise version of Access.  So, if you created the .accde using 64-bit Access then ONLY 64-bit versions of Access can run it no matter what you do with conditional compilation.  I think vice-versa it true also.  Conditional compilation only works if you distribute an .accdb.
I distribute .accdb files that are both 32 and 64-bit compatible. The way I do it is to use a compiler directive constant that works for 99% of all the API calls out there. Here's an example:

#If VBA7 Then
    '* 64-bit declarations, which will work in Access 2010 and later, 32 and 64-bit versions
    Private Declare PtrSafe Function GetTextMetrics Lib "gdi32" Alias "GetTextMetricsA" (ByVal hDC As LongPtr, lpMetrics As TEXTMETRIC) As Long
    Dim mhDC As LongPtr
    '* 32-bit declarations for 32-bit versions of Access before Access 2010
    Private Declare Function GetTextMetrics Lib "gdi32" Alias "GetTextMetricsA" (ByVal hDC As Long, lpMetrics As TEXTMETRIC) As Long
    Dim mhDC As Long
#End If

Open in new window

... and here's how that function would be used:

lngret = GetTextMetrics(mhDC, tmTEXTMETRIC)

Open in new window

I never had a lot of joy from conditional compiling as an end-user no intervention required solution.
A2007+ have the PITA of FilterOnLoad with a default of true.

I figured I go

#If Application.Version > 11
#End If

That looks nice.
But if I compiled it on A2003 and pushed it out, that PITA afflicted every up-level user, and if I compiled it on A2007, then everything was broken for the A2003 users because the references got shot.

Conditional compiling is nice, it lets you compile two different versions from the same source code.
But YOU as the developer have to create and push out multiple properly compiled versions to the clients.
As a far as I know, you can't get VBA to compile the project dynamically.
I could be wrong, though...
Checking VBA7 alone is not enough.    That only tells you if your running in vba7.   It's win64 that tells you if your running 64 bit.

Fyi there is a sys cmd call to force vba to compile.   I'll dig it out.  But if it were me, I'd never compile on the fly.  Too many things can go wrong.

Jim, the 64-bit declarations are valid in VBA7, regardless of whether you are running in 32 or 64 bit.

There are SOME api calls that will require a check for Win64, but as I said my approach works for about 99% of api calls that I've come across.

So  like I said, you need both.   For a handful of calls, in 64 bit the actual call changed.

 But if you are only going to use one, then win64 would be a better choice.  In the code example you gave, you'd be executing your 64 bit call for both 32 and 64 bit.   With Win64, which is only true in a 64 bit environment, your 32 bit call would always be called in a 32 bit environment, and 64 bit call in 64 bit environments. That would cover 100% of the cases then.

With that said, I'm not aware of any down side to using prtsafe and longptr in a 32 bit environment other than using more memory and giving up some performance.

Avatar of WORKS2020
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
unable to find a resolution
I think we've all misunderstood what you needed.
I meant to say I can't install.
We still don't know what that meant.
You purchased a product that was based on a 32 bit MS Access 2007 database, and therefore you couldn't install it?
And so you returned that product because it was incompatible with your existing systems?