How can a user tell what version of MS Access they are using

[mouldh]

Hopefully someone can help me.

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.

Thanks

 

[isladogs]

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

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

 

[mouldh]

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.

 

[isladogs]

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:

 

[mouldh]

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.

 

[arnelgp]

Or you can simply use

Application.version

 

[isladogs]

Or you can simply use

Application.version

You can indeed. It will give results like 14.0 for Access 2010
What you choose just depends on the amount of detail you want to get.

EDIT:

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.

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:

Me.lblVersion.Caption = GetAccessEXEVersion

 

[The_Doc_Man]

Find C:\Program Files (x86)\Microsoft Office\Office?\

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.

 

[isladogs]

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

 

[The_Doc_Man]

Colin (Ridders)

Whilst users could search Program Files for the folder containing their version of Access, why should they need to do so?

OP (Mouldh)

I don't want to check the user's version via code, I would like the users to check the version themselves.

OP (Mouldh)

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.

 

[gemma-the-husky]

Does it matter?

Why would it cause a problem if they used a newer version?

 

[isladogs]

Does it matter?

Why would it cause a problem if they used a newer version?

Obviously I don't know why it matters for the OP.

In my case, I provide this information to clients mainly for my own use when dealing with support issues related to a reported bug

 

[gemma-the-husky]

@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.

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.

 

[isladogs]

@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.

Good point though not my interpretation.

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.

This could be interpreted in more than one way
Hopefully the OP will return to let us know. They seem to be MIA at the moment