AOB
Registered User.
- Local time
- Today, 12:05
- Joined
- Sep 26, 2012
- Messages
- 621
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. :
...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
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