Runtime crash at startup

[drjdbb]

Dear all,
I have developed a db using Access 2013 (Office365) as a desktop application. (64 bit)
I am now trying to make it transferrable to users who have only the runtime version of access.

I have:

• 
  Used Option Explicit for every module / form / report / class etc

• 
  Converted as much of my VBA to late binding and removed references down to the minimum (OLE Automation, VB for A, MS Access 15.0 Obj Lib, MS Office 15 Access DB engine Object lib - this last one I can also remove I believe)

• 
  Added error handling to EVERY procedure - even the 'one-liners'

• 
  Added Form and Report 'On Error" handling as well with "Response = acDataErrContinue" specified.

• 
  Decompiled and Compacted my db

• 
  Created a new db and then imported all objects to the new db

• 
  Run the file on my full version Access using the /runtime emulator.

My problem is that on my own computer, I have no errors.
I have installed Access Runtime 2016 on my wife's computer (64bit) and as soon as I run the file, I get a Runtime error and the program shuts down.
At one stage, I managed to trap an error relating to a module (which I had deleted already). But this trappable error disappeared after a decompile.
Given some "issues" with backwards compatibility between 2016 and 2013 - shouldn't be an issue because I don't have ULS nor pivot tables), I have uninstalled the 2016 runtime and re-installed 2013 runtime on the wifes computer - same problems.

All my error handling attempts to Log the error to a table, AFTER messaging the user. None of this happens. I get the generic runtime error and it shuts down.

From my reading, I have focussed on the references. As stated above, I initially minimised it down to just 3 refences, but have since added the Engine Object Library back in, as Microsoft suggest this is a default.

I have also tried to find all the referenced files. On my computer, they do not all exist in the locations specified by the Reference manager or by directly enumerating the reference properties via VBA. However, I found them all by searches, and have then ensured they all exist on the target computer.
Because of differences in tree structure, the folder I have copVBEied them into match as close as possible the destinations specified by the Reference manager (and not where they were on my computer). (Note: I only needed to copy the Engine Object Library (ACEDAO.dll) and VB for A library (VBE7.1.dll)

I am at a loss as to how to proceed. :banghead:
Any help and advice appreciated.

 

[Ranman256]

sometimes its not the code, its the flavor of runtime vs the database.
Ive had to use Access 2010 with an older runtime to get it to work.

 

[drjdbb]

sometimes its not the code, its the flavor of runtime vs the database.
Ive had to use Access 2010 with an older runtime to get it to work.

It can't be that 'hit-and-miss'

 

[Cronk]

I've had similar experiences with run time. Sometimes.

The trouble is with run time, it's not easy to see where the issue is.

In situations where all users were using the same run time file, I've solved it by having them each run their own copy of the run time. Sometimes, the user area decided to insist their IT support install full version Access.

Sorry cannot be more helpful.

 

[drjdbb]

I also tried 2010 Runtime - no joy.

 

[bob fitz]

I had a similar problem with A2013 runtime. I can't remember the details of the problem now but I do remember that I installed my full version of access on the users machine to get to the bottom of the problem and then uninstalled it.

 

[JHB]

Have you tried to make a very simple database, a few tables/forms only for finding out if it is an issuer with the runtime or with you application.

 

[drjdbb]

Have you tried to make a very simple database, a few tables/forms only for finding out if it is an issuer with the runtime or with you application.

Thanks but yes. The backend file works fine. It has tables, one form (a cut down version of the navigation form used in the frontend - complete with Form_Load VBA) and one module.
It works fine.

 

[Minty]

Make sure that the other machines have all their windows updates installed and are up to date. We had a machine here that wouldn't run a database on runtime 2010 or 2013 that was running fine on all others. Windows updates sorted it out.

There are some issues with 32 bit Access vs 64 bit. have a look here for some discussion http://www.utteraccess.com/forum/32bit-Runtime-64bit-Runt-t1995392.html

 

[JHB]

Okay - if me I would add more forms, reports and modules, (one by one), until you find the culprit.

 

[drjdbb]

Okay,

So I have narrowed down the issue - to a particular form. I will probably take this problem to a new thread now after some research. But for those following I would recommend the following:
Firstly check

• Windows and Office Updates
• References
• 64 v 32 bit declarations
• Third party programs used by your app

I ended up (as suggested above) creating a whole bunch of copies of the db removing components and gradually adding them back in.
I would suggest starting by removing all the forms and reports, as these IMHO the most likely to be the source of the issue. (Also far less likely to cause compile issues -so long as you're not trying to actually do stuff with the db while going through this process.)
If you have to do the same with all the modules, then you'll have to comment out large amounts of the forms' and reports' VBA to allow compiling.
Try each of these versions on the Runtime Computer.
Hopefully that will narrow things down for you.

My issue came down to a form that I have for manipulating images.
This form uses irfanview for manipulating images.
Firstly I ensured that this was installed on target computer - no change.
I then realised that all the declarations were 32 bit versions. (WHY this wasn't causing issues on my computer - which is 64 bit as well - I don't know?). I swapped over to the 64 bit declarations, and now I can at least open the database on the runtime computer. However, if I try to access that form, it crashes again. I'm now looking at the declarations with a magnifying glass. If I can't fix it myself - I guess you'll see a new thread somewhere...

Thanks all.