Run time errors on new installations

[rjcarlson49]

I have a large application that was originally developed in Access 2007, but now I am using Access 2016. The users are remote and we see many problems getting the app to run in a run time only environment. There seems to be no rhyme nor reason to the various problems. We have them install the latest run time directly from the M$ site first. Sometimes this works as it is supposed to but often there will be run time errors when the DB is started up.

Sometimes this can be fixed by random changes like uninstalling the run time and reinstalling it. Sometimes we need to install more than one version of the run time. Sometimes we never find a fix. With Access installed, there is almost never a problem, though sometimes we see a transient issue.

What might be behind these problems? What is a foolproof method for installing run time only users?

[CJ_London]

There seems to be no rhyme nor reason to the various problems

there will be a reason

For starters

Is your code fully compiled with option Explicit at the top of every module - just below Option Compare Database?

Are you using late binding?

Are all users using the same 'bit' version of access - 64 bit usually requires changes to the code if developed in 32bit

Do you have full error handling? - runtime will just bomb out if there is no error handling - perhaps users can't see the backend.

if using runtime, it must be the same bit and version as the front end development machine, but this may be in conflict with the rest of the office suite which can cause issues, although a later runtime version may run an app developed on an earlier machine

You really need to log the details of all pc's which are failing and look for the patterns of failure

[rjcarlson49]

Thanks

Yes, option explicit is in every module

I'm not sure what you mean by late binding in this context

Error handling is as full as I can figure out how to make it, these run time errors do not invoke my error handling. The DBs are all local, in the same folder as the DB with the code or in a folder just under it.

All the development is on 64 bit machines and 64 bit Office. Can this lead to issues on a 32 bit target machine?

[CJ_London]

I'm not sure what you mean by late binding in this context

if your app uses libraries for excel/outlook etc. and users have a mixture of 2007/10/13/16 they need to be late bound

Can this lead to issues on a 32 bit target machine?

To be clear, I am talking about the bit of Office, not the machine. clearly a 32 machine cannot have installed a 64bit version of access. But a 64bit machine can have installed a 32bit version of office. 64 bit access cannot run a 32bit .accde and a 32 bit access cannot run a 64bit .accde. If you are providing a .accdb, you need to ensure you are declaring variables correctly in and API calls you are using - this includes using PtrSafe and using Long for 32bit or LongLong for 64bit for pointers, or using the hybrid LongPtr.

The DBs are all local, in the same folder as the DB with the code or in a folder just under it.

Don't understand what this means

[rjcarlson49]

Regarding the last thing. I provide all the code in an accdr file, ie not compiled. Early on we had trouble distributing accde files so I just went with the accdr. The data is kept in an accdb file. This is furnished as an empty file that can be copied to create multiple instances of the data. There is a switching mechanism in the code to switch instances of the data. All instances of the data are local, no networking. The failures seem to occur before the code even runs enough to connect the correct accdb.

I googled around and figured out what you meant by late binding. You are talking binding to the code, not the data. I do not do any late binding of code, but I am not using any other Office products, but I have several "references" of course.

Do you have any idea which of these might not be present on a system which has had the 2016 run time installed?

Visual Basic for Applications
Microsoft Access 16.0 Object Library
OLE Automation
Microsoft Office 16.0 Access database engine Object Library
Microsoft Office 16.0 Object Library
Microsoft Scripting Runtime
Microsoft ActiveX Data Objects 6.0 Library

They seemed like safe bets to me.

[CJ_London]

.accdr is just a file name change - anyone with full access will open it as a runtime app, but if they change the extension back to .accdb they will have full access (subject to anything else you do). The first 4 are 'standard' so should not be a problem - although earlier versions of accesses will not run it. Of the remaining ones, Scripting Runtime doesn't have a version so should be OK and the last one should be late bound (think it is the ADODB library). The 5th one (Office v16) requires the relevant version of office to be installed, otherwise should be late bound. Not sure of the impact if the machine does not have office installed at all

[rjcarlson49]

I'm aware that people can open the code if they want to. It has not been a problem in our case.

I will look into late binding those. Thanks. I suspect though that the result will be just that I can give a good error message. That should be enough.