Perpetual Access license + Runtime

Many thanks for your responses.

I would appreciate a Yes/No answer to the following, if possible.
1) Can I install just the M365 Runtime on a pc without M365? (BTW, I will try it later on today)
2) I can download the latest M365 Runtime from Microsoft 365 Access Runtime Online Installer but would like to be able to install a specific Runtime for my clients so that they all have the same Runtime and maybe develop in a specific version of Access. Can I develop in a specific version of Access and distribute a specific version of the Runtime.

If I install a C2R Runtime (ie versions 16/19/22/365) on a client's pc, it appears that this client can no longer use Access. Is this the case?
 
Many thanks for the answers.

If you can elaborate a bit more on the provisos, it would be very helpful.

BTW, I find the "disabling" of Access once the Runtime is used as provocative to say the last and intrusive.

4) Once a Runtime is installed, does this Runtime get updated automatically as time goes by?
 
No - you have already been advised in other posts to this thread. The main one being to develop in the earliest version your clients use - and be aware if supplying a.accde it is bit sensitive- 32bit access won’t run a 64bit .accde and visa versa

Can’t answer 4.
 
Just to let you know that on a VM I have 64bit A2013
No - you have already been advised in other posts to this thread. The main one being to develop in the earliest version your clients use - and be aware if supplying a.accde it is bit sensitive- 32bit access won’t run a 64bit .accde and visa versa

Can’t answer 4.
I am aware of the bitness issue and I have 2 .accde's, the correct one being downloaded after a bitness check.

It would be interesting to know whether the Runtime is updated in the same manner as is the Access software. My guess is that it is updated bearing in mind that the Runtime is a version of the software. Will continue to receive a firm reply.
 
Just to let you know that on a VM I have 64bit A2013

I am aware of the bitness issue and I have 2 .accde's, the correct one being downloaded after a bitness check.

It would be interesting to know whether the Runtime is updated in the same manner as is the Access software. My guess is that it is updated bearing in mind that the Runtime is a version of the software. Will continue to receive a firm reply.
In the after-hours session in our recent user group meeting, several of us tried to figure out an answer to that question, unsuccessfully. If you can verify it for us, one way or the other, that would be great. I'm not really sure how one would go about doing that, so if you figure that out, that would also be helpful.
 
It would be interesting to know whether the Runtime is updated in the same manner as is the Access software.

Obviously, with the run-time version, you don't have easy ability to get into the File >> Help (older versions) or File >> Account pathway to get it to show you the current build number.

I don't have the requisite run-time software for a test, but there might be an easy way for Win11.

Find the folder in which your run-time file is installed. Not the run-time app but the Access Run-time program itself. Open that folder so all the files are displayed in Details view. Now bring the mouse pointer to hover over the file you want. At least for me, when I hover over a .EXE file that has an explicit version number, it shows me a little box with the file's version, size, and creation date. I have tried to take a screen shot showing that display, but when I touch any key, the little floating box goes away before the "Print Screen" key captures the image.

Then there is also the chance that you check the "Last Modified" date and see if it got updated. That should work for ANY version of Windows.
 
BTW, I find the "disabling" of Access once the Runtime is used as provocative to say the last and intrusive.
The last version of Access to open typically "owns" the extensions. That means that when you have more than one version of Access installed on your PC (which is never recommended, although you can do it) you need to pick the Access version you want before you open an app. You do that either by opening Access and then picking the file to open or your create a shortcut that opens a specific version of Access and passes in the name of the file you want it to open.
 
The last version of Access to open typically "owns" the extensions. That means that when you have more than one version of Access installed on your PC (which is never recommended, although you can do it) you need to pick the Access version you want before you open an app. You do that either by opening Access and then picking the file to open or your create a shortcut that opens a specific version of Access and passes in the name of the file you want it to open.
My comment about Access being disabled does not refer to multiple instances of Access. If you have one instance of A365 and install the Runtime, I can no longer use Access for development purposes.

As I have mentioned above, with A2013 I can have the 2013 Runtime installed and I am still able to use A2013 for development purposes.

What is entirely unacceptable is the fact that if you install the Runtime on a client's pc, that client cannot use Access.
 
What is entirely unacceptable is the fact that if you install the Runtime on a client's pc, that client cannot use Access.

I suppose it IS frustrating, but the logic here escapes me. You put Access Runtime on a PC because the person doesn't HAVE Access and therefore cannot open an app file normally. If they had Access, they wouldn't need the Runtime version. It just seems to be an inversion of the normal purpose of Runtime. Therefore, I cannot say I'm surprised that in a non-traditional use of Runtime, things go a bit awry. Not criticizing, just observing the logic of the situation. I wonder if you are asking more than Runtime was intended to do.
 
I suppose it IS frustrating, but the logic here escapes me. You put Access Runtime on a PC because the person doesn't HAVE Access and therefore cannot open an app file normally. If they had Access, they wouldn't need the Runtime version. It just seems to be an inversion of the normal purpose of Runtime. Therefore, I cannot say I'm surprised that in a non-traditional use of Runtime, things go a bit awry. Not criticizing, just observing the logic of the situation. I wonder if you are asking more than Runtime was intended to do.
If a user has bought the Full Microsoft Access application, why should he not be able to use it if the Runtime is installed?

In my mind the Runtime is used when deploying an application and it should be independent of whether the user has the Full version installed. It makes the installation more independent.

It appears that all deployment scripts should be changed to check first if the Full version exists and if it exists then not install the Runtime. Also, not everyone uses MS Office and problems will arise, if they happen to have MS Office on their pc and then remove it for some reason.
 
It appears that all deployment scripts should be changed to check first if the Full version exists and if it exists then not install the Runtime. Also, not everyone uses MS Office and problems will arise, if they happen to have MS Office on their pc and then remove it for some reason.

We check for the presence of an Access install in our installer scripts, for a number of reasons, the one mentioned above and what version and "bitness" they are running. We also need to check what SQL Driver they have (if any) and install that as well in most cases
The installer package has both 32 & 64 bit runtimes available and installs the most appropriate one and the matching accde.
We only install anything if the app won't run without the install.

It's a relatively moot point as 95% of our clients are on O365 subs anyway, so they just need an up-to-date SQL ODBC Driver.
 
We check for the presence of an Access install in our installer scripts, for a number of reasons, the one mentioned above and what version and "bitness" they are running. We also need to check what SQL Driver they have (if any) and install that as well in most cases
The installer package has both 32 & 64 bit runtimes available and installs the most appropriate one and the matching accde.
We only install anything if the app won't run without the install.

It's a relatively moot point as 95% of our clients are on O365 subs anyway, so they just need an up-to-date SQL ODBC Driver.
Sounds good. We have an application which uses A365 as FE and SQL Server as BE and it works well. We have managed to create an automatic update of the .accde whenever there is a new .accde. The update is very fast and the user does not even realize that there was an update.

Can I ask what deployment tool you use? Inno?
 
If a user has bought the Full Microsoft Access application, why should he not be able to use it if the Runtime is installed?

In my mind the Runtime is used when deploying an application and it should be independent of whether the user has the Full version installed. It makes the installation more independent.

It appears that all deployment scripts should be changed to check first if the Full version exists and if it exists then not install the Runtime. Also, not everyone uses MS Office and problems will arise, if they happen to have MS Office on their pc and then remove it for some reason.
A good few programs advise you to remove any previous versions before installing the new version?
 
A good few programs advise you to remove any previous versions before installing the new version?
Understood. As it was mentioned before, it is possible to have A2013 Full and A2013 Runtime working with no problem on the same pc. It is the same program with the Runtime having some of the functionality removed. Why couldn't his be the case with M365?
 
We use Sam Logic Visual Installer.
It's pretty simple to use once you get used to it.

Many thanks. I tried using SamLogic and proved a bit difficult. I contacted them and ask them to install it on my pc and I would pay for it. My proposal was not met.
 

Users who are viewing this thread

Back
Top Bottom