determine if access runtime 2010 is installed (1 Viewer)

[perlfan]

Hi,

I like to determine if a user has Access Runtime 2010 installed (because if not I want to start a download process and install it).

Is there a unique registry key that I can check? Havn't found it despite extensive googling.... thx for help!!

Frank

 

[spikepl]

So what is wrong with what you get by stuffing "determine if a user has Access Runtime 2010 installed" into google?

 

[perlfan]

Nothing! Well, I didn't post my problem here because I've a working solution elsewhere....

There are discussion on the topic - e.g. have I tried KEY_LOCAL_MACHINE,'SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Access\InstallRoot but it's not working for detecting if AR 2010 is on the system or not.

 

[spikepl]

Since 12.0 refers to Office 2007 no wonder it does not tell you if A2010 runtime is installed. You need 14.0

 

[spikepl]

Function GetAccessPath() As String
    Dim objFSO As Object
    Dim sAccessDir As String
    Dim sFileVersion As String
    Dim sHKLM As String
    Dim WshShell As Object

    Set WshShell = CreateObject("WScript.Shell")

    ' Determine 32/64-bit Processor Architecture
    If InStr(1, _
             WshShell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%"), _
             "64") > 0 Then
        sHKLM = "HKLM\SOFTWARE\Wow6432Node\"
    Else
        sHKLM = "HKLM\SOFTWARE\"
    End If

    ' Retrieve the directory for MSACCESS.EXE
    sAccessDir = WshShell.RegRead(sHKLM _
                                  & "Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE\Path")

    Set WshShell = Nothing

    Set objFSO = CreateObject("Scripting.FileSystemObject")
    sFileVersion = objFSO.GetFileVersion(sAccessDir & "MSACCESS.EXE")
    Set objFSO = Nothing

    Select Case Split(sFileVersion, ".")(0)
        Case "8"
            ' 97
        Case "9"
            ' 2000
        Case "10"
            ' 2002
        Case "11"
            ' 2003
        Case "12"
            ' 2007
        Case "14"
            ' 2010
            Debug.Print "2010"
        Case "15"
            ' 2013
            Debug.Print "2013"
    End Select
    GetAccessPath = sAccessDir & "msaccess.exe"
End Function

Surely you do not care whether it is Runtime or full version? The above code tells you if you have any Access installed.

 

[perlfan]

True, it's Office 14. Doesn't work either.

It's exactly what I want: to determine if Runtime is installed, so that every user is running the app on the same conditions. And download / installation shall only be initiated if Runtime is not installed.

Regards, Frank

 

[CJ_London]

retype your db as accdr which will force everyone to run in runtime, even if they have access installed.

And if you use package and sign there is an option to install runtime if the full version is not installed

 

[perlfan]

I'm using Inno. Seems as if I have to give my goal to determine between Access full version and Access Runtime....

 

[Frothingslosh]

While I've never tried to do it, my expectation would be that either you can't install the runtime on a machine with the same or a later version of Access on it, or it could cause conflicts.

If you take CJ_London's advice and deploy as an accdr file (and you can do this to both accdb and accde files), then it won't matter if they have a full install, as even a full install will act as the runtime when running the file. If you have users changing it back FROM accdr, then that's a personnel problem.

 

[CJ_London]

 I'm using Inno

What is Inno?

 

[spikepl]

perlfan - if you have a fancy Inno script pls do share

CJ_London : free Installer

 

[perlfan]

accdr is nice. I used the .accde /runtime shortcut till now which works too, but the simpler the better.

On my machine with Access 2010 full version and Runtime 2010 accdr opens in Runtime. On my partners machine with Access 2007 full version and Runtime 2010 the accdr file starts an Access 2007 configuration process which ends in an error stating that the file has been compiled with a newer Access version than 2007.... :-/ I thought I could force it to open the file with Access 2010....does anybody where the bug is?

BTW: I attached my inno script. You need the inno downloader for it as it downloads the accessruntime only if not installed. It's not perfect, so advice is always welcome....

 

[perlfan]

So in the meantime I found out that

Running the .accdr forces runtime mode but doesn't force the actual use of the runtime engine.

http://www.access-programmers.co.uk/forums/showthread.php?t=232883

So my question is: how can I force the system to use the Runtime engine??

 

[spikepl]

Your issue is not the engine as such but version. Access does this reconfiguration thing if you have two versions installed at the same time.

Some time ago there was a post - i reckon in this forum - by a user who managed to find a couple of registry settings which allowed him to select which Access version he wanted to run without going through this reconfiguration process. I'd suggest you use this google link (set to search AWF only) http://www.google.co.uk/advanced_se...en&cr=countryUK|countryGB&safe=off&as_qdr=all

and try with keywords like
versions
registry

etc


And thx for the INNO -thing

 

[CJ_London]

It may be that using the access installer rather than inno may solve the problem since it may be doing more than you have scripted inno to do

 

[perlfan]

@spikepl: Unfortunately I didn't find anything on a possible workaround....
@CJ_London: Inno is so much more flexible than the developer tools. And I don't think that the tools will force Windows to use the Runtime engine instead of switching a full version into Runtime mode.

For me, the "solution" will be to compile with an older Access version (2007) instead of with 2010 to prevent (reconfiguration) errors caused by older Access full versions simply put in Runtime mode....

 

[spikepl]

2nd post while googling "access version registry" on AWF :

http://www.access-programmers.co.uk/forums/showthread.php?t=269745

It is not a workaround as such - it allows you to avoid the version switching behaviour if you insist on having two access versions installed at the same time

 

[CJ_London]

And I don't think that the tools will force Windows to use the Runtime engine

I didn't say it would, I'm suggesting it might solve the problem 'which ends in an error stating that the file has been compiled with a newer Access version than 2007'