Solved VBScript to determine bitness of local MS Access version (1 Viewer)

AOB

Registered User.
Local time
Today, 03:37
Joined
Sep 26, 2012
Messages
570
Hi there,

I've run into some difficulties with a distributed Access DB (that is, a central ACCDB backend with distributed ACCDE frontends) The front end utilises some API's which obviously have to be declared differently in the two configurations (made pointer-safe in 64-bit) and I've discovered that even if I build the ACCDE on a 32-bit machine, there are issues when trying to open it on a 64-bit machine (and vice versa) My guess is that the issue lies with the fact that ACCDE's are pre-compiled, executable-only files (whereas ACCDB's are compiled at run-time) therefore whichever version of Access you build the ACCDE in, will not work in a conflicting configuration.

In other words, even if you conditionalise the declarations, i.e. :

Code:
#If VBA7 Then
    Private Declare PtrSafe Sub GetSystemInfo Lib "kernel32" (lpSystemInfo As SYSTEM_INFO)
#Else
    Private Declare Sub GetSystemInfo Lib "kernel32" (lpSystemInfo As SYSTEM_INFO)
#End If

...because the ACCDE is already pre-compiled when the user goes to run it, if their configuration doesn't match that of the version that did the compile, it's not going to work.

As luck would have it, as a rule, I use a launch script on the server; users have a local shortcut which points to the script which pulls down the latest version of the front-end to their local device and runs it. I've always used this model as it's a handy way of distributing updates without having to push new versions to each users device.

My plan (and feel free to tell me I'm barking up a wrong tree here) is to build two versions of the same fundamental ACCDE, one on a 32-bit machine (with 32-bit-safe declarations) and another on a 64-bit machine (with 64-bit-safe declarations) and host both versions on the network. And then modify that launch script so that when the user runs it, the script can determine the bitness of the local version of Access (32-bit or 64-bit) and pull down the version of the ACCDE that is appropriate for their local version (thus circumventing the pre-compile problem)

I was going to simply check the Office version and run the 32-bit version for v15.x / Office 2013 or below, and the 64-bit version for v16.x / M365 and above (by querying WMI Service with Select * from CIM_Datafile Where against the app paths returned from the registry via both HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE and HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE)

But I'm trying to do this as robustly as possible (i.e. a catch-all solution that can be used as a template for other DB's) and I'm conscious that you can have 64-bit configurations of earlier versions and, indeed, 32-bit versions of later versions (even though, I think, in my particular case, these are rare, if indeed possibly non-existent)

So - very long-winded way of asking...

Does anybody know a good way, via VB Script, of determining the bitness of the locally installed version of Access (as opposed to simply the major version) ?

Thanks

AOB
 

Ranman256

Well-known member
Local time
Yesterday, 22:37
Joined
Apr 9, 2015
Messages
4,088
paste into a module . Usage: msgbox Is64Bit()


Code:
Public Function Is64bit() As Boolean
    #If Win64 Then
      Is64bit = True
    #Else
      Is64bit = False
    #End If
End Function
 
  • Like
Reactions: AOB

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 10:37
Joined
May 7, 2009
Messages
16,080
vscript sample:
Code:
   Dim shell, GetOSBits, oAccess
   Dim path
   Set shell = CreateObject("WScript.Shell")
   If shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%") = "AMD64" Then
      GetOsBits = "64"
   Else
      GetOsBits = "32"
   End If
   Set shell=Nothing
   Set oAccess = CreateObject("Access.Application")
   path = oAccess.syscmd(9)
   oAccess.Quit
   set oAccess=Nothing
 
   wscript.echo GetOSBits
   wscript.echo path

   If GetOSBits = "64" And Instr(1, path,"Program Files (x86)") = 0 Then
      wscript.echo "Office is x64"
   else
      wscript.echo "Office is x86"
   end if
 
Last edited:
  • Like
Reactions: AOB

AOB

Registered User.
Local time
Today, 03:37
Joined
Sep 26, 2012
Messages
570
paste into a module . Usage: msgbox Is64Bit()


Code:
Public Function Is64bit() As Boolean
    #If Win64 Then
      Is64bit = True
    #Else
      Is64bit = False
    #End If
End Function
Thanks @Ranman256 but this is VBA, not VBScript - VBA not an option as I need to determine the bitness before I launch the ACCDE
 

AOB

Registered User.
Local time
Today, 03:37
Joined
Sep 26, 2012
Messages
570
vscript sample:
Code:
   Dim shell, GetOSBits, oAccess
   Dim path
   Set shell = CreateObject("WScript.Shell")
   If shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%") = "AMD64" Then
      GetOsBits = "64"
   Else
      GetOsBits = "32"
   End If
   Set shell=Nothing
   Set oAccess = CreateObject("Access.Application")
   path = oAccess.syscmd(9)
   oAccess.Quit
   set oAccess=Nothing

   wscript.echo GetOSBits
   wscript.echo path

   If GetOSBits = "64" And Instr(1, path,"Program Files (x86)") = 0 Then
      wscript.echo "Office is x64"
   else
      wscript.echo "Office is x86"
   end if
Thanks @arnelgp - this seems to work pretty well!

I made one modification as I don't particularly want to launch Access (in order to determine the path to the MSACCESS.EXE), then exit and relaunch Access again - so I subbed that part out and replaced it with a registry read :

Code:
Set objShell = WScript.CreateObject("WScript.Shell")

strProcessorArchitecture = objShell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
If strProcessorArchitecture = "AMD64" Then
    strOSBitness = "64"
Else
    strOSBitness = "32"
End If
    
strRegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE\Path"
strMSAccessExePath = objShell.RegRead(strRegKey) & "MSACCESS.EXE"

If strOSBitness = "64" And Instr(1, strMSAccessExePath, "Program Files (x86)") = 0 Then
    ' 64-bit version of MS Access is installed locally - copy over the 64-bit compiled version
    strNetworkFileName = strNetworkFileName64
Else
    ' 32-bit version of MS Access is installed locally - copy over the 32-bit compiled version
    strNetworkFileName = strNetworkFileName32
End If
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 19:37
Joined
Oct 29, 2018
Messages
18,745
Thanks @arnelgp - this seems to work pretty well!

I made one modification as I don't particularly want to launch Access (in order to determine the path to the MSACCESS.EXE), then exit and relaunch Access again - so I subbed that part out and replaced it with a registry read :

Code:
Set objShell = WScript.CreateObject("WScript.Shell")

strProcessorArchitecture = objShell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
If strProcessorArchitecture = "AMD64" Then
    strOSBitness = "64"
Else
    strOSBitness = "32"
End If
   
strRegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE\Path"
strMSAccessExePath = objShell.RegRead(strRegKey) & "MSACCESS.EXE"

If strOSBitness = "64" And Instr(1, strMSAccessExePath, "Program Files (x86)") = 0 Then
    ' 64-bit version of MS Access is installed locally - copy over the 64-bit compiled version
    strNetworkFileName = strNetworkFileName64
Else
    ' 32-bit version of MS Access is installed locally - copy over the 32-bit compiled version
    strNetworkFileName = strNetworkFileName32
End If
Just FYI, if it's ever possible that a user would have a C2R version of Access installed, you might want to add a test for that also. Cheers!
 
  • Like
Reactions: AOB

AOB

Registered User.
Local time
Today, 03:37
Joined
Sep 26, 2012
Messages
570
Just FYI, if it's ever possible that a user would have a C2R version of Access installed, you might want to add a test for that also. Cheers!
Very good point! I don't think Click-To-Run is used much here but I shall file this in the "Maybe" column for the next time it falls over! 😵🤪
 

Users who are viewing this thread

Top Bottom