As long as a database is split, is it okay if front ends are a mix of 64 bit and 32 bit installs? (1 Viewer)

CindyKredo

New member
Local time
Today, 03:36
Joined
Nov 8, 2019
Messages
19
Given that Microsoft is now defaulting installations to 64 bit, I'm revamping some 32 bit code to work in either 32 or 64 bit installations. I vaguely recall once reading that users should all be on the same platform - does anyone know if this is the case? As long as each user has their own front end, am I okay if some users are using a 32 bit installation, and others have a 64 bit install?
 

Dreamweaver

Well-known member
Local time
Today, 10:36
Joined
Nov 28, 2005
Messages
2,466
I think you can mix front ends there have been a number of post which sugest they do just that.

mick
 

GinaWhipp

AWF VIP
Local time
Today, 06:36
Joined
Jun 21, 2011
Messages
5,901
Yes, you can mix as long as the Frontend is not shared.
 

isladogs

MVP / VIP
Local time
Today, 10:36
Joined
Jan 14, 2017
Messages
18,186
The only issues you would have are
1. Needing to use conditional compilation for API declarations / types if any users are still on A2007 or earlier
2. Supplying both 32-bit and 64-bit versions if the FE is an ACCDE file
3. Managing issues with any ActiveX controls or VBA references hat haven't been updated for 64-bit.

If none of those apply, you're good to go without any additional work.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 10:36
Joined
Sep 12, 2006
Messages
15,614
@Colin

2. Supplying both 32-bit and 64-bit versions if the FE is an ACCDE file

Is that right - you can't put a conditional compile declaration inside a .de database and have it run on both from the same build?

I have this code block to manage reading/writing INIFiles, but it's not tested yet in 64bit Office. . The mde works fine, but I have 32bit Access and this is built into an mde on the same machine. Does the compiler include both bits of code, or just the bit for the current instance of Access.

Code:
#If VBA7 Then
     #If Win64 Then
        private Declare ptrsafe Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long  'For ini read
        Private Declare ptrsafe Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long  'For ini write
    #Else
        Private Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long   'For ini read
        Private Declare Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, Bed to build 3 versionsd
yVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long   'For ini write
    #End If
#Else
    Private Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long   'For ini read
    Private Declare Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long   'For ini write
#End If


just to clarify, I thought ptrsafe might be acceptable to 32bit access, but it isn't, and not having ptrsafe is equally not acceptable to 64bit access.

On reflection, given my above block, do I need 3 versions, or can I get away with 2 builds.
a) VBA6, on A32
b) VBA7+ on A32
c) VBA7+ on A64
 
Last edited:

isladogs

MVP / VIP
Local time
Today, 10:36
Joined
Jan 14, 2017
Messages
18,186
@Colin
Is that right - you can't put a conditional compile declaration inside a .de database and have it run on both from the same build?
....

Unlike ACCDB files, ACCDE files will only run in the same bitness they were created in.
If you try to run in the 'wrong' bitness an error message is shown

I include both versions of the ACCDE file with my installer packages.
The installer detects the Office 'bitness' then only installs the correct version.

I do use conditional compilation in my ACCDB files.
When the project is compiled as ACCDE only the relevant parts of the code are included for that bitness.

However your conditional compilation is more complicated than it needs to be.
It took me several years to realise that the #If Win64 part is superfluous

If you have users on A2007 or earlier (VBA6) as well as both bitnesses from A2010 or later (VBA7), this construct works

Code:
#If VBA7 Then
'use PtrSafe as well as LongPtr for handles/pointers
#Else
 ...
#End If

If all users are on A2010 or later, just use the declaration for the VBA7 part without conditions

I have this code block to manage reading/writing INIFiles, but it's not tested yet in 64bit Office. . The mde works fine, but I have 32bit Access and this is built into an mde on the same machine. Does the compiler include both bits of code, or just the bit for the current instance of Access.

just to clarify, I thought ptrsafe might be acceptable to 32bit access, but it isn't, and not having ptrsafe is equally not acceptable to 64bit access.

To reiterate, PtrSafe was added to VBA7 so isn't recognised by A2007 or earlier.
It is fine in A2010 or later whether 32-bit or 64-bit.
However 64-bit requires the use of PtrSafe.

I haven't checked your code sample but can do so if you wish
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 10:36
Joined
Sep 12, 2006
Messages
15,614
@Colin

Thanks. That's cleared up a couple of my misconceptions then. Time I stopped using A2003 I think.
 

isladogs

MVP / VIP
Local time
Today, 10:36
Joined
Jan 14, 2017
Messages
18,186
A2003 was excellent but is very old and long since stopped being supported
I still use A2010 (also soon to go out of support) and, in my opinion that was the best version of Access ever.
I also use A365 but really dislike the interface for A2016/2019/365 and the recent major bugs have reinforced my dislike of that product
 

Users who are viewing this thread

Top Bottom