Access Runtime

[JohnPapa]

Can A2013 Runtime coexist with A365 Runtime?

More specifically, if A2013 Runtime already exists, can the A365 Runtime be installed?

 

[GPGeorge]

Can A2013 Runtime coexist with A365 Runtime?

More specifically, if A2013 Runtime already exists, can the A365 Runtime be installed?

Two questions come to mind.

Why would it be useful to install both versions on a computer? I.e. under what circumstances would this be done, if it were possible?

What happens when you try? I assume you have both installers, so why not try to install both versions to see what happens.

 

[Pat Hartman]

Although it makes sense to have multiple versions of Access installed for development, it makes no sense to have multiple versions of the runtime installed. You should install the oldest version of the Runtime that works for your app.

 

[The_Doc_Man]

There is also the issue that if you were using Ac2013 as a DEVELOPMENT environment to support an AC2013 app, that ONE TOUCH of Ofc365 to open that file will automatically update library references, after which the 2013 environment will have a hard time working with it. SERIOUSLY hard time.

 

[Edgar_]

Can A2013 Runtime coexist with A365 Runtime?

More specifically, if A2013 Runtime already exists, can the A365 Runtime be installed?

Check @isladogs article:
https://www.isladogs.co.uk/office-dual-install/index.html#RUN

 

[sonic8]

it makes no sense to have multiple versions of the runtime installed.

It makes sense, if multiple Access databases with different requirements are used.
I've got a client who needs the A2010 runtime to still use a legacy ADP application but also needs a current A365 installation to use a different database with Modern Charts.

 

[Pat Hartman]

It makes sense, if multiple Access databases with different requirements are used.

Not unless one version of Access wouldn't run them all and that would be very unusual. Frequently you want different full and Runtime or multiple full but I've never seen a situation where you would need multiple runtimes. That would be a shop with heavy Access usage and no one who ever converted old apps to newer versions. Strange indeed.

 

[JohnPapa]

Let me shed some light on this with a real problem at hand.

We have a software package stored in probably 200 locations and this works fine the A2013 Runtime. The software package is as complicated as it gets and we cannot remain forever in A2013, due to tableID restrictions etc. We will move to A365 and would like to use the A365 Runtime and was wondering, based on your experience whether both Runtimes can coexist during the transition phase.

In the general case I would agree with sonic8 above, there are cases where a developer does not want to invest the time to change a software package to make it compatible with another Runtime and would rather use the Runtime he is sure that the software works with.

I will look at the Colin's suggestion in #5, but the question is "can the A2013 and A365 Runtime coexist?"

 

[JohnPapa]

Colin's article in #5 is useful, but could not find an answer to the specific question, "can the A2013 and A365 Runtime coexist?"

I have today prepared a new pc and I will try it out and will report.

BTW, not everyone wants to have Office on their PC, so having both Runtimes is a solution for some cases.

 

[The_Doc_Man]

I can't tell you WHEN it happened specifically, because my old memory isn't 100% reliable, but MS moved towards isolating multiple versions of Office by creating working folders with the major version number as a suffix to "Office" - but the version number isn't the year number. You could find that Office 2003 was actually [...Office11]. Office 2013 was actually [...Office15]. I don't know just HOW thorough the separation was, but you could install two relatively recent but different versions easily enough.

The downer on the situation is that the Associations (that trick that Access uses to know what to launch when you double-click on an application file) are associated to one version only. So that means that if you installed a later version AFTER the earlier version, the only way to launch the earlier app with the correct version of Access is to edit a shortcut icon. In which you include the explicit path to the desired version of Access (if it isn't the one selected by the current Associations.)

 

[JohnPapa]

Here are the findings.
I used an A2013 .accde and an A365 .accde

On a pc running Windows 11, I had installed Office 2013 (including A2013) and A2013 Runtime.

I installed A365 with no problem and I ran the program using a shortcut whose Target was something like C:\AppDir\AppName.accde /Runtime

I then uninstalled Office 2013 and was left with A2013 Runtime and A365 Runtime. I was able to run both. I am not sure but I believe it used the A365 Runtime.

I uninstalled A365 runtime and was left with Access 2013 runtime. Was not able to run A365 .accde.

I then uninstalled A2013 Runtime and installed A365 Runtime. Can run both, which leads me to believe that in the presence of both Runtimes the later Runtime is the default.

Questions:
1) Is there a way to know which Runtime is used?
2) Can the user force the use of a specific Runtime?

 

[patrickharris]

Yes, different Access runtime versions can coexist on the same machine. They install into separate folders. Just be sure to compile your accde/accda files with the correct version.

 

[JohnPapa]

Yes, different Access runtime versions can coexist on the same machine. They install into separate folders. Just be sure to compile your accde/accda files with the correct version

Microsoft can be a bit sneaky...
The A2013 Rutime was saved in
C:\Program Files (x86)\Microsoft Office\Office15

While the A365 Runtime was saved in
C:\Program Files (x86)\Microsoft Office\root\Office16

To confuse everybody there is an "Office16" folder at the same level as folder "root"

If you fully define the path to MSAccess.exe,

you can run the Access2013 Runtime using
"C:\Program Files (x86)\Microsoft Office\Office15\MSACCESS.EXE" "C:\AppFolder\AppName.accde" /runtime

you can run the Access365 Runtime using
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\AppFolder\AppName.accde" /runtime

 

[Pat Hartman]

I installed A365 with no problem and I ran the program using a shortcut whose Target was something like C:\AppDir\AppName.accde /Runtime

This doesn't change the version of Access that runs the program. What it does is it tells whatever version of Access that Windows has associated with the .accde to open the database and PRETEND to be the Runtime engine. So you could have A2013 or O365 in control of the .accde - no way to tell. You need to look at the Windows file associations in order to determine what Application Windows will run in this scenario.

To control what program opens your application, you MUST use a shortcut that opens Access (whatever version) and passes in the name of the .accde you are trying to open. Otherwise, as Doc mentioned, you are at the mercy of Windows and the file association process and have no control over what app will actually run your database.

Multiple versions of Access will fight over who owns a particular extension. THAT is the major issue you run into since the last version of Access to open takes over the file association. I have no idea what happens if you try to open two different applications at the same time, each with a different version of Access but you should figure this out before committing to this plan. Once you have multiple versions of Access installed, YOU need to open Access and then open the app. You can no longer rely on the file association to always open the correct version.

The other major issue involves OLE automation. This issue you probably need to solve by switching from late binding to early binding so you pick the Office version at compile time rather than at run time.

It is bad enough when YOU, the developer, have to deal with multiple installed versions. I would never inflict this on a user willingly.

Newer versions of Access usually run applications created with older versions without issue. You always need to be careful about clean compiles but if you deliver .accde's then that is taken care of. That leaves you with the bitness incompatibility which is harder to deal with because that requires that you create the .accde's with the same bit version that will run the app.

 

[Cotswold]

I always installed RunTime on customers' PCs to prevent them running the program using a different version of Access to my developed version. If they had the same version of Access installed, I still used RunTime, just in case they installed a later version afterwards. But mainly because I wanted to be in control of the system setup. I automated the setup with an executable install file created from a batch file. Then some bright spark couldn't tinker with the setup as the .EXE prevented that. I'd allow them to have the BE wherever they preferred, locally or away on a server. But the FE was always where I wanted it to be. Much easier for support. Last thing I wanted was someone there thinking they knew what they were doing.

I'd have a specifically named folder off the C:\ and installed RunTime into that. Off the same folder I'd then have a folder for each of the software packages they had. Each program had a desktop shortcut to open RunTime with the program as a parameter. Never had a conflict, or issue.

 

[JohnPapa]

This doesn't change the version of Access that runs the program. What it does is it tells whatever version of Access that Windows has associated with the .accde to open the database and PRETEND to be the Runtime engine. So you could have A2013 or O365 in control of the .accde - no way to tell. You need to look at the Windows file associations in order to determine what Application Windows will run in this scenario.

To control what program opens your application, you MUST use a shortcut that opens Access (whatever version) and passes in the name of the .accde you are trying to open. Otherwise, as Doc mentioned, you are at the mercy of Windows and the file association process and have no control over what app will actually run your database.

Multiple versions of Access will fight over who owns a particular extension. THAT is the major issue you run into since the last version of Access to open takes over the file association. I have no idea what happens if you try to open two different applications at the same time, each with a different version of Access but you should figure this out before committing to this plan. Once you have multiple versions of Access installed, YOU need to open Access and then open the app. You can no longer rely on the file association to always open the correct version.

The other major issue involves OLE automation. This issue you probably need to solve by switching from late binding to early binding so you pick the Office version at compile time rather than at run time.

It is bad enough when YOU, the developer, have to deal with multiple installed versions. I would never inflict this on a user willingly.

Newer versions of Access usually run applications created with older versions without issue. You always need to be careful about clean compiles but if you deliver .accde's then that is taken care of. That leaves you with the bitness incompatibility which is harder to deal with because that requires that you create the .accde's with the same bit version that will run the app.

Thanks for the info. I believe #13 clears matters.

In my case I need to move from A2013 Runtime to the A365 Runtime and being able to install the A365 Runtime without disrupting the existing A2013 setup is very useful. It will only be an interim solution until the migration is complete.

 

[JohnPapa]

I always installed RunTime on customers' PCs to prevent them running the program using a different version of Access to my developed version. If they had the same version of Access installed, I still used RunTime, just in case they installed a later version afterwards. But mainly because I wanted to be in control of the system setup. I automated the setup with an executable install file created from a batch file. Then some bright spark couldn't tinker with the setup as the .EXE prevented that. I'd allow them to have the BE wherever they preferred, locally or away on a server. But the FE was always where I wanted it to be. Much easier for support. Last thing I wanted was someone there thinking they knew what they were doing.

I'd have a specifically named folder off the C:\ and installed RunTime into that. Off the same folder I'd then have a folder for each of the software packages they had. Each program had a desktop shortcut to open RunTime with the program as a parameter. Never had a conflict, or issue.

Can you control the folder where the Runtime is stored?

 

[Cotswold]

Can you control the folder where the Runtime is stored?

Like I said, I simply installed it into a folder that I had created.
I have located a very, very old install instruction and just amended it by removing the company and program names. Maybe that will help.
Without spending quite a lot of time I haven't any details about later improved versions, or the batch file .EXE files I used but you should get the idea.
TIP! Don't use spaces in filenames, or folder names.

 

[Pat Hartman]

This doesn't change the version of Access that runs the program. What it does is it tells whatever version of Access that Windows has associated with the .accde to open the database and PRETEND to be the Runtime engine. So you could have A2013 or O365 in control of the .accde - no way to tell. You need to look at the Windows file associations in order to determine what Application Windows will run in this scenario.

This is what you need to understand. When you have multiple versions of Access installed, they fight over the registry and who has control over which file extensions. Therefore, to be certain that each application is run using your intended version of Access, you must open Access first, then run the app. To make that happen, you use a shortcut that runs Access (from wherever) and passes the name of your app as an argument. The /Runtime argument doesn't do what you seem to think it does.

 

[Isaac]

My experience in trying to run multiple Access versions on a machine - even for dev, frankly, but certainly for deployment/end users, is a nightmare. Whack a mole solve one problem another arises. I'd avoid it. Decide on a version and go with it. I never go with the newest versions, they have all the bugs.