32 vs 64 bit versions of Access, how to convert

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

#Else
' 32 bit api calls

#End If

Select allOpen in new window

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
http://msdn.microsoft.com/en-us/library/office/gg278832(v=office.15).aspx
http://msdn.microsoft.com/en-us/library/office/ee691831(v=office.14).aspx

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
http://technet.microsoft.com/en-us/library/ee833946.aspx

also read:

 Compatibility Between the 32-bit and 64-bit Versions of Office 2010
http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx

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

All the new 64 bit calls are here:
http://www.microsoft.com/download/en/confirmation.aspx?displaylang=en&id=9970

a list of all the calls that were modified for 64 bit:
http://msdn.microsoft.com/en-us/library/aa383663(VS.85).aspx

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.

Jim.

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
#Else
    '* 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

Select allOpen in new window

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

lngret = GetTextMetrics(mhDC, tmTEXTMETRIC)

Select allOpen 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
    Me.FilterOnLoad=False
#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.
Sigh.
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.

Jim

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

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.

@peter,

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.

Jim.

unable to find a resolution

I think we've all misunderstood what you needed.
I meant to say I can't install.
@WORKS2011
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?