Issues with MS Access Runtime and Office 365... please help.
Hi everyone,
After doing ALOT of reading and research, I turn to the experts to help me out. We have an MS Access Application that is used by hundreds of customers. It was originally built on MS 2007 but through the years we have upgraded all the way to development in Ms Access 2013.
We have quite a few customers that have installed Office 365 in different languages (ex: French and Spanish). For our MS Access application the underlined MS Access program has to be in English.
We installed MS Access runtime 2013, but very often we get a weird on open Err:0 "can't find the object xxx". The only temporary fix was to transfer the application to a PC with Office 365 in English and open it there. It would open normally, then we would return the application back to the original PC until it happens again. That's not a viable solutions.
We tried to install MS Access Runtime 2016 but it does not allow it to be installed with Click to Run Office.
Finally we installed MS Access Runtime 365 and it allows to open however it is really slow. We wanted to tweak the registry setting (ie MaxBufferSize) but can't seem to find the location in the registry.
Has anyone else had this problem? This whole CTR thing is becoming a real problem.
Any advice would be greatly appreciated.
Regards,
TSIsolutions
After doing ALOT of reading and research, I turn to the experts to help me out. We have an MS Access Application that is used by hundreds of customers. It was originally built on MS 2007 but through the years we have upgraded all the way to development in Ms Access 2013.
We have quite a few customers that have installed Office 365 in different languages (ex: French and Spanish). For our MS Access application the underlined MS Access program has to be in English.
We installed MS Access runtime 2013, but very often we get a weird on open Err:0 "can't find the object xxx". The only temporary fix was to transfer the application to a PC with Office 365 in English and open it there. It would open normally, then we would return the application back to the original PC until it happens again. That's not a viable solutions.
We tried to install MS Access Runtime 2016 but it does not allow it to be installed with Click to Run Office.
Finally we installed MS Access Runtime 365 and it allows to open however it is really slow. We wanted to tweak the registry setting (ie MaxBufferSize) but can't seem to find the location in the registry.
Has anyone else had this problem? This whole CTR thing is becoming a real problem.
Any advice would be greatly appreciated.
Regards,
TSIsolutions
You might want to consider an AppLauncher, which would copy the latest version of the application from your network to the users PC every time they want to launch the application.
This ensures that you won't have the backwards incompatibility issue Daniel mentioned.
It also ensures that you don't have any bloat associated with temp tables.
But the key to using an AppLauncher is to make sure that he version of the database on the network cannot be opened by someone who knows the location. I usually use an AutoExec macro and a function which checks to see whether the left most character of currentproject.fullname = "C", and if not, I display a warning message and quit the application.
This ensures that you won't have the backwards incompatibility issue Daniel mentioned.
It also ensures that you don't have any bloat associated with temp tables.
But the key to using an AppLauncher is to make sure that he version of the database on the network cannot be opened by someone who knows the location. I usually use an AutoExec macro and a function which checks to see whether the left most character of currentproject.fullname = "C", and if not, I display a warning message and quit the application.
ASKER
Hi Daniel,
Thanks for your answer. The issue doesn't lie in broken or missing references. We have a module that checks for all broken and missing references and most (if not all) of the code was switched to Late Binding years ago.
It is not a code issue as the application works until a change is done in the MS Office installation/environement and then something breaks.
We have to rethink our distribution strategy moving forward as it will be important to check if Office CTR is installed and install MS Access runtime CTR instead of MSI... but that's a different discussion.
For now, we need a way to optimize our MS Access application running on Ms Access Runtime 365 CTR but I have no idea where to change the registry settings for it. For example In CTR, the following doesn't exist:
Computer\HKEY_LOCAL_MACHIN
Any advice on where it is located?
Thanks for your answer. The issue doesn't lie in broken or missing references. We have a module that checks for all broken and missing references and most (if not all) of the code was switched to Late Binding years ago.
It is not a code issue as the application works until a change is done in the MS Office installation/environement and then something breaks.
We have to rethink our distribution strategy moving forward as it will be important to check if Office CTR is installed and install MS Access runtime CTR instead of MSI... but that's a different discussion.
For now, we need a way to optimize our MS Access application running on Ms Access Runtime 365 CTR but I have no idea where to change the registry settings for it. For example In CTR, the following doesn't exist:
Computer\HKEY_LOCAL_MACHIN
Any advice on where it is located?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with Jim. Don't mess with the registry directly and simply use the single line SetOption at the startup of your database, refer to https://docs.microsoft.com
This kind of issues are best dealt by using Late Binding..the issue is that the applications has hardcoded the path to the .dll/.ocx that uses but due to localization is almost "natural" to have troubles...i even had a heck of issues due to regional settings like the system delimiter,time/date settings and so on.
The issue doesn't lie in broken or missing references
It is not a code issueI wouldn't give my 2 cents on it.
Did you investigate on wich part of code is breaking ?
Whenever a break occure, did you investigate references / ocxs ?
Were you able to reproduce reliably ?
Also, maybe it is time to adapt for international portability.
ASKER
Thanks everyone for your input.
I will try and use Jim's idea to set the MaxBuffer and MaxLocksPerFile from the application.
As John mentioned Late Binding is a must with any serious Ms Access development. Unless you want to spend your time looking over dll/ocx registration and version numbers... that use to be our nightmare.
Fabrice, thanks for your input. The error occurs as soon as we execute the app.
We tried over and over to reproduce the error but we think it has something to do with opening Office 365 and then opening RT 2013.. but it was still unpredictable. Not exactly sure what you mean by "international portability"
As I wrote, the work-around leads me to believe that there are incompatibilities between Office 365 and Ms Access Runtime versions (in my case it was 2013). The "easy" fix was to switch from RT 2013 to RT 2016 CTR.
Moving forward we will have to, as Dale Fye mentioned, create an autoexec that check the current version and downloads accordingly or use an App Launcher like Total Access Startup.
Just like a lot of you, I'm getting frustrated by the amount of issues that can arise from developing in MS Access... especially when they're not caused by code and development but rather caused by new versions and OS changes.
I will try and use Jim's idea to set the MaxBuffer and MaxLocksPerFile from the application.
As John mentioned Late Binding is a must with any serious Ms Access development. Unless you want to spend your time looking over dll/ocx registration and version numbers... that use to be our nightmare.
Fabrice, thanks for your input. The error occurs as soon as we execute the app.
We tried over and over to reproduce the error but we think it has something to do with opening Office 365 and then opening RT 2013.. but it was still unpredictable. Not exactly sure what you mean by "international portability"
As I wrote, the work-around leads me to believe that there are incompatibilities between Office 365 and Ms Access Runtime versions (in my case it was 2013). The "easy" fix was to switch from RT 2013 to RT 2016 CTR.
Moving forward we will have to, as Dale Fye mentioned, create an autoexec that check the current version and downloads accordingly or use an App Launcher like Total Access Startup.
Just like a lot of you, I'm getting frustrated by the amount of issues that can arise from developing in MS Access... especially when they're not caused by code and development but rather caused by new versions and OS changes.
Just like a lot of you, I'm getting frustrated by the amount of issues that can arise from developing in MS Access... especially when they're not caused by code and development but rather caused by new versions and OS changes.
That's always been true though and always will be as it's Access's biggest problem; an Access app is more like a document that is read rather than a true program (compiled/linked .EXE). So it's very sensitive to its environment at run-time.
I think more problematic in the Office space right now is the different install types (MSI, CTR, and now Store) and the issues that surround 32 vs 64 bit. From Office 2013 and up, you can't mix install types within a single version, and you can't mix bit types across any of those versions either.
One other problem is the fact that the major version number did not change with O2016 and O2019 (they both read as version 16.0), but there are "versions" which is not exposed that I'm aware of along with a build number within that version. You can see those here:
https://docs.microsoft.com/en-us/officeupdates/update-history-office-2019
and here:
https://docs.microsoft.com/en-us/officeupdates/update-history-office365-proplus-by-date
So yes, it's pretty messy at the moment to distribute Access applications. I think though Microsoft is getting a handle on things and once we get past this transition it will get a lot smoother going forward.
Jim.
Is typically caused by a missing reference, which is usually caused by the database being developed (or used at one point) on a newer version of Access than is currently being used to run it.
For instance, the db is run on Access 2016 (so Access upgrades the references to 2016) and then you run it in 2013, you will get such headaches.
When you get this issue, did you check the references in the VBE?
Did you ensure that VBA code compiled without issues?
Did you try decompiling & recompiling on the problematic machines?
Also, ActiveX controls can play a role especially when a db is being run on x64 versions of Office! Could bitness be playing a role here?
Of course! You are not alone in the least. It is an absolute mess managing Windows & Office nowadays (versions, update channels, builds, bitness, CTR/MSI, ...).