Latest version of Access with a Runtime
- Thread starter JohnPapa
- Start date
tvanstiphout
Active member
- Local time
- Today, 13:55
- Joined
- Jan 22, 2016
- Messages
- 370
We also have the 365 version: https://support.microsoft.com/en-us...-runtime-185c5a32-8ba9-491e-ac76-91cbe3ea09c9
Once the next perpetual version comes out (likely sometime later in 2024), a runtime will likely follow.
Once the next perpetual version comes out (likely sometime later in 2024), a runtime will likely follow.
- Local time
- Today, 21:55
- Joined
- Sep 12, 2006
- Messages
- 15,980
Could you not install the full version, and leave it unlicensed? Will it degrade to runtime?
Thanks for your replies. I have two cases I need to take care of:
1) I have several applications built on A13 (uses ACE as the BE) using its runtime, which works very well with Windows 7, 8, 10 & 11. I know that some of the above are not actively supported by MS.
2) I have just finished an application which I developed on the 365 version of Access (uses SQL server as BE). I cannot expect the user to have Access 365 on their pc.
My initial thought is to migrate to a version of Access and use its runtime, for the sake of stability and to be independent of MS Office. I know it is best not to use the latest version of Access, but I would not mind trying A24 when it comes out. I would then have the problem of support in the various Windows environments.
1) I have several applications built on A13 (uses ACE as the BE) using its runtime, which works very well with Windows 7, 8, 10 & 11. I know that some of the above are not actively supported by MS.
2) I have just finished an application which I developed on the 365 version of Access (uses SQL server as BE). I cannot expect the user to have Access 365 on their pc.
My initial thought is to migrate to a version of Access and use its runtime, for the sake of stability and to be independent of MS Office. I know it is best not to use the latest version of Access, but I would not mind trying A24 when it comes out. I would then have the problem of support in the various Windows environments.
- Local time
- Today, 16:55
- Joined
- Feb 19, 2002
- Messages
- 46,866
It is always safer to develop in the LOWEST version that you have to distribute. So it may be "fun" to always have the latest and greatest, but if your user base can't keep up, you will end up with developing using features that the user's version of Access cannot support.
Remember that the Runtime will be used and it will be independent of any Access installed on the user's pc.
- Local time
- Today, 16:55
- Joined
- Feb 19, 2002
- Messages
- 46,866
It doesn't matter. Either develop in the same version as the Runtime or a lower version. When you develop in a higer version is when you run the risk of using some not supported tool. People break their apps this way all the time. They make the mistake of trying a new feature in their test copy of a database. Sometimes, when you use a feature Access "remembers" even if you deleted the form or other object and now your text copy of the FE is technically corrupted because no earlier version can run it. You then go on to make a modification and move it into production and users get strange errors related to the phantom feature.
If you develop with a newer version, you must be judicious in remembering to never test any concept related to a new feature in anything other than a throw-away database.
Agree with everything you say.
I never use third party software. Even the calendar I made up from textboxes, so my code is reasonable portable.
The biggest problem would be the Windows that the software runs on. With A13, it can run on Windows 7, 8, 10 & 11. With higher versions of Access, the choices are limited.
- Local time
- Today, 16:55
- Joined
- Feb 19, 2002
- Messages
- 46,866
I'm not talking about ActiveX controls. I'm talking about native Access new features. I can't think off hand of the ways I've broken apps by mindlessly testing some new feature in my test version of a production app and forgetting I did it. But I have and the only remedy is to delete whatever object you tested on and then create a new FE and import all other objects into it because even deleting the object that used the "feature" would prevent earlier versions of Access from opening the app after you tried the new thing because Access had some hidden setting that had been flipped and didn't get unflipped when you removed the new feature.
Just came across the following
Download and install Microsoft 365 Access Runtime - Microsoft Support
Does anyone have any practical experience with this? I will read up on this later, since I have to leave right now.
- When installing the Access 365 Runtime on a machine that has another Click-to-Run version of Office installed, the Access Runtime installed will match that of the existing Office installation. For instance, if the machine has Office 2021 installed, Access 2021 Runtime will be installed.
Download and install Microsoft 365 Access Runtime - Microsoft Support
Does anyone have any practical experience with this? I will read up on this later, since I have to leave right now.
At the end of the day, it would be unreasonable to expect the user to have Office installed, so I believe that for the sake of stability, a specific version of Access should be used, say A21 and the specific Runtime should be installed.
- Local time
- Today, 21:55
- Joined
- Feb 19, 2013
- Messages
- 17,397
Not sure what your concern is
user does not have office installed - the 365 version of access is installed (I believe is 2019)
user has office 2007/10/13/16/whatever installed but excluding Access - the relevant version of runtime is installed
user has office 2007/10/13/16/whatever installed including full access - no download of runtime
note: not sure how far back runtime versions would go.
2016 onwards still use the same 'version', the differences in later versions are generally cosmetic and relate to design capabilities which would not be relevant for runtime
see this link for version comparisons
why is it unreasonable to expect the user to have Office installed?
A bigger concern for me would be if users a) are capable of using 64bit access (depends on machine/windows version/capacity but unlikely unless they have old tech) and b) they install the right 'bit' version if you are providing an .accde.
user does not have office installed - the 365 version of access is installed (I believe is 2019)
user has office 2007/10/13/16/whatever installed but excluding Access - the relevant version of runtime is installed
user has office 2007/10/13/16/whatever installed including full access - no download of runtime
note: not sure how far back runtime versions would go.
2016 onwards still use the same 'version', the differences in later versions are generally cosmetic and relate to design capabilities which would not be relevant for runtime
see this link for version comparisons
Microsoft Access Version Features and Differences Comparison Matrix
Microsoft Access Version Differences with database formats, field types, security, containers, form and report features, discontinued features, etc.
fmsinc.com
why is it unreasonable to expect the user to have Office installed?
A bigger concern for me would be if users a) are capable of using 64bit access (depends on machine/windows version/capacity but unlikely unless they have old tech) and b) they install the right 'bit' version if you are providing an .accde.
Similar threads
