All our users use MS Access Runtime to access our databases, but they have different versions of MS Access Runtime. How can they tell which version of MS Access Runtime they have? In a non-Runtime version you would look in Help, About, but that isn't available in MS Access Runtime.
I rarely use runtime so someone may have an easier method than this.
However, it can be done via code using a button click:
4 functions below. Choose whichever is most useful to you.
Example results shown
a) GetAccessEXEVersion e.g. Access 2010 SP2 14.0.7162
b) GetAccessBuildVersion e.g. 14.0.7162
c) GetAccessVersion e.g. 14
d) IsOfficex64 e.g. 32-bit
You can combine d) with any of a) - c) to give e.g. Access 2010 SP2 14.0.7162 32-bit
By default, results are shown in the immediate window - a MsgBox may be better for your purposes
Code:
Function GetAccessEXEVersion() As String
'Valid for use with Access 2000 or later.
'Original version may be from Tom van Stiphout, not sure?
'SysCmd(715) -> 6606
'Application.Version OR SysCmd(acSysCmdAccessVer) -> 12.0
On Error Resume Next
Dim sAccessVerNo As String
sAccessVerNo = SysCmd(acSysCmdAccessVer) & "." & SysCmd(715)
Select Case sAccessVerNo
'Access 2000
Case "9.0.0.0000" To "9.0.0.2999": GetAccessEXEVersion = "Access 2000 " & sAccessVerNo & ""
Case "9.0.0.3000" To "9.0.0.3999": GetAccessEXEVersion = "Access 2000 SP1 " & sAccessVerNo & ""
Case "9.0.0.4000" To "9.0.0.4999": GetAccessEXEVersion = "Access 2000 SP2 " & sAccessVerNo & ""
Case "9.0.0.6000" To "9.0.0.6999": GetAccessEXEVersion = "Access 2000 SP3 " & sAccessVerNo & ""
'Access 2002
Case "10.0.2000.0" To "10.0.2999.9": GetAccessEXEVersion = "Access 2002 " & sAccessVerNo & ""
Case "10.0.3000.0" To "10.0.3999.9": GetAccessEXEVersion = "Access 2002 SP1 " & sAccessVerNo & ""
Case "10.0.4000.0" To "10.0.4999.9": GetAccessEXEVersion = "Access 2002 SP2 " & sAccessVerNo & ""
'Access 2003
Case "11.0.0000.0" To "11.0.5999.9999": GetAccessEXEVersion = "Access 2003 " & sAccessVerNo & ""
Case "11.0.6000.0" To "11.0.6999.9999": GetAccessEXEVersion = "Access 2003 SP1 " & sAccessVerNo & ""
Case "11.0.7000.0" To "11.0.7999.9999": GetAccessEXEVersion = "Access 2003 SP2 " & sAccessVerNo & ""
Case "11.0.8000.0" To "11.0.8999.9999": GetAccessEXEVersion = "Access 2003 SP3 " & sAccessVerNo & ""
'Access 2007
Case "12.0.0000.0" To "12.0.5999.9999": GetAccessEXEVersion = "Access 2007 " & sAccessVerNo & ""
Case "12.0.6211.0" To "12.0.6422.9999": GetAccessEXEVersion = "Access 2007 SP1 " & sAccessVerNo & ""
Case "12.0.6423.0" To "12.0.5999.9999": GetAccessEXEVersion = "Access 2007 SP2 " & sAccessVerNo & ""
'Access 2010
Case "14.0.0000.0000" To "14.0.6022.1000": GetAccessEXEVersion = "Access 2010 " & sAccessVerNo & ""
Case "14.0.6023.1000" To "14.0.7014.9999": GetAccessEXEVersion = "Access 2010 SP1 " & sAccessVerNo & ""
Case "14.0.7015.1000" To "14.0.9999.9999": GetAccessEXEVersion = "Access 2010 SP2 " & sAccessVerNo & ""
'Access 2013
Case "15.0.0000.0000" To "15.0.4569.1505": GetAccessEXEVersion = "Access 2013 " & sAccessVerNo & ""
Case "15.0.4569.1506" To "15.0.9999.9999": GetAccessEXEVersion = "Access 2013 SP1 " & sAccessVerNo & ""
'Access 2016 - to be confirmed
Case "16.0.0000.0000" To "16.0.4569.1505": GetAccessEXEVersion = "Access 2016 " & sAccessVerNo & ""
Case "16.0.4569.1506" To "16.0.9999.9999": GetAccessEXEVersion = "Access 2016 SP1 " & sAccessVerNo & ""
Case Else: GetAccessEXEVersion = "Access - Unknown Version"
End Select
If SysCmd(acSysCmdRuntime) Then GetAccessEXEVersion = GetAccessEXEVersion & " Run-time"
'Debug.Print GetAccessEXEVersion
End Function
Function GetAccessBuildVersion() As String
'CR 29/05/2012
'Gets full Access version number including program updates / service packs
'e.g. 14.6024 for Access 2010 SP1
GetAccessBuildVersion = Nz(SysCmd(acSysCmdAccessVer) & "." & SysCmd(715), "None")
'Debug.Print GetAccessBuildVersion
End Function
Function GetAccessVersion() As String
'CR modified 29/05/2012 - NEW CODE Gets Access version e.g. 14 for Access 2010
GetAccessVersion = Nz(CInt(SysCmd(acSysCmdAccessVer)), "None")
'Debug.Print GetAccessVersion
End Function
Function IsOfficex64()
'checks if Office is 32 or 64 bit
#If Win64 Then
IsOfficex64 = "64-bit"
#Else
IsOfficex64 = "32-bit"
#End If
'Debug.Print IsOfficex64
End Function
Thank you for such a quick and comprehensive reply, but I don't want to check the user's version via code, I would like the users to check the version themselves. As I said, if they had a full version of MS Access they would be able to do that, but I don't know how they can do that with a Runtime version of MS Access.
I don't think they can - that's why I offered code.
In some of my databases, the Access version (& other info) is displayed on the main form using functions like those:
Ah, thanks. There are a few different databases, I don't particularly want to update them all to find this information out, but maybe I'm going to have to.
Thanks for your help.
Whichever method you choose, you can use exactly the same process on each app
e.g. create an unbound label called lblVersion.
Then in your Form_Load event add a line similar to this:
The ? governs what version of Office is installed. Office14 is actually Office 2010.
According to what I could look up, you cannot have Access Runtime and Access "Full" on the same machine at the same time because the names are the same for the two. Therefore, find MSACCESS.EXE in the folder path I suggested.
Right-click that to get properties. In that multi-panel dialog box, look for Details. In the details screen look for the product name.
Since all of those steps are benign, it would be safe to have folks look for them that way. You could also find this from the registry, but that's not usually a good idea for folks who don't understand the registry.
According to what I could look up, you cannot have Access Runtime and Access "Full" on the same machine at the same time because the names are the same for the two. Therefore, find MSACCESS.EXE in the folder path I suggested.
Doc
You can have 2 Access installations on the same machine ... providing they are different versions
e.g. I have both 2010 & 2016 on this computer for convenience when testing my applications.
As the file names are always the same, they obviously need to be installed to different folders
Whilst users could search Program Files for the folder containing their version of Access, why should they need to do so?
Much better to just use a function to show this info on a form as in my earlier screenshot ... or click a button to get the info displayed
Also, the default file path for recent versions is a bit more complex.
For Access 2016, I have C:\Program Files\Microsoft Office\root\Office16\MSAccess.exe
All our users use MS Access Runtime to access our databases, but they have different versions of MS Access Runtime.
...
if they had a full version of MS Access they would be able to do that
It would seem to me based on information already in the thread that the Windows file-type association must point to the Runtime version, and that the further implication is that whether or not it is possible for a seasoned Access professional to have run-time and a full version on the same system, the people in question do not.
Therefore I described a manual, non-code method of determining what is on the system.
I was thinking more that if the issue is users sharing a single database, and using different versions of access then it might be causing a references problem? In which case the real issue is not to share front ends.
I think the problem is that in general Access will try to use the same version it used last time. I don't think there is a direct way of telling access to use A2003 for one database, A2010 for another and A2016 for a third. If the last database you used was A2010, then it will use A2010 for the next database. You can have dedicated desktop short cuts to pick the correct version, and I think I have seen 3rd party apps to manage it. You still might get the issue of versions having to reinstall when you change from one to the other.
@ridders
I was thinking more that if the issue is users sharing a single database, and using different versions of access then it might be causing a references problem? In which case the real issue is not to share front ends.
