I am aware of the bitness issue and I have 2 .accde's, the correct one being downloaded after a bitness check.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.
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.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.
It would be interesting to know whether the Runtime is updated in the same manner as is the Access software.
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.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.
What is entirely unacceptable is the fact that if you install the Runtime on a client's pc, that client cannot use Access.
If a user has bought the Full Microsoft Access application, why should he not be able to use it if the Runtime is installed?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.
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.
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.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.
A good few programs advise you to remove any previous versions before installing the new version?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.
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?A good few programs advise you to remove any previous versions before installing the new version?
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.We use Sam Logic Visual Installer.
It's pretty simple to use once you get used to it.
SamLogic Visual Installer - Installation Software / Setup Tool / Setup Wizard - for Windows
Installation software with many powerful functions. With the Visual Installer setup tool you can create a setup program / setup wizard for your Windows software for distribution via CD, DVD, USB flash drive & Internet.www.samlogic.net