Run-time crash with Runtime Access

[twgonder]

Windows 10 & 11, Access 2021 & 364



I've got my little demo together. It's worked fine on two laptops.
I split the db and placed the BE on yet another hardware.
Then for fun I loaded the 64-bit version of the Access 365 Runtime onto that third hardware.
When I opened and closed a form, I got the "Execution of this application has stopped due to a run-time error".
And now I get that message at startup when I double click on the .accdb file.
Yet the same .accdb FE file continues to run fine without errors on the two laptops.
Just to be sure, I decompiled, and redistributed the .accdb file.

Is the Office 365 Runtime supposed to be compatible with the Office 2021 Access?
Has anyone had compatibility problems like this?
How can I check that 64-bit Runtime was actually installed? (I don't see any about in the Runtime version)

Thanks

[Minty]

There are issues with installing different versions on the same machine.

I would have a read of Colin's excellent article here: https://isladogs.co.uk/office-dual-install/index.html

[twgonder]

@ Minty, post#2 Thanks for the link, I'll read for the information.

In the current case, no single machine has more than one version. It's that the downloaded 365 Runtime doesn't seem to play well with a .accdb created on an Access 2021. The run-time errors aren't consistent, so that points to the 365 Runtime and not the .accdb which works just fine with the same simple tasks on a full Access 2021.

[twgonder]

An update on what I've found (not a solution as of yet)

On the desktop 3 machine (mini computer, Windows 11):
I uninstalled the 365 Runtime, and rebooted.
Installed the 2016 Access Runtime, and rebooted.
Created a directory for a test of integrated .accdb (non-split, so as to avoid possible link issues)

On laptop 1:
Tested the integrated .accdb (worked fine)
Moved the integrated .accdb from laptop 1 to desktop 3
Ran the integrated .accdb on desktop 3 from laptop1 (everything running over the wire), worked fine.

On Desktop 3:
Tried running the same integrated .accdb using the 2016 Runtime. RTE and stops

The reading and training class I did said that Runtimes should...just run.
Are there some mods to an .accdb that one needs to make to work on a Runtime that I neglected?

I still can't confirm that the Runtimes that were installed are indeed 64-bit even though that's what I chose for the install.

[Minty]

I'm going to assume that the accdb's compile ok?
That's definitely a necessity.

[twgonder]

@Minty, post#5

Yes, and to be sure, I just did it all over again, with a compile, compact, etc.

And put it on another laptop (2) and tried two different .accdb files.
They both failed with a RTE on laptop 2 Runtime 2016 (as best as I can recall, because, again, MS doesn't seem to want to divulge which Runtime is installed (at least as I can find).

I run the files from laptop 1, which has full Access 2021, over the wire and the files run fine, no RTE.

[twgonder]

I haven't seen otherwise, but I'm guessing that one can run a .accdb as well as .accde on the Runtime versions.

[Welshgasman]

Wouldn't the file location give a clue?

https://superuser.com/questions/1588...ice%5COfficeNN

[CJ_London]

I'm guessing that one can run a .accdb as well as .accde on the Runtime versions

You can, and by changing the file extension to .accdr, you can open the file from full access but emulating runtime

[isladogs]

An easy way of testing the bitness of the runtime version.
Try and run an ACCDE file. If it errors, then its the 'other' bitness.

[twgonder]

@CJ_London post #9 That's good to know, thanks. I can test if to see if that "r" file messes up the full version.
Can one run the "r" on a runtime version too without problems? (I'm trying to cut down on all the files I have.

I'm also wondering if there is some kind of internal Access log, or event log, that would show the possible source of the RTE when I open with the Runtime version, since the RTE there doesn't help very much.

[CJ_London]

Can one run the "r" on a runtime version too without problems? (I'm trying to cut down on all the files I have.

yes - it is really intended as a development tool, but some will use it in production as a very simple (and easily overcome) security method - all a user has to do is change it back to .accde/b

I'm also wondering if there is some kind of internal Access log, or event log, that would show the possible source of the RTE when I open with the Runtime version, since the RTE there doesn't help very much.

Not from runtime - basically that is what error handling does. There is the windows management interface which I believe reports errors but I've never used it. Others may have a better idea but here is a link
https://learn.microsoft.com/en-gb/wi...isdk/using-wmi


if you are struggling to get past the first post, start your opening code with a msgbox and insert another one after each line of code or code segment. Crude, but effective. Alternatively write to a log table.

[twgonder]

@CJ_London, post #12 Thanks for the info on "R". I read someone mention the "r", but they didn't way what it's for.
I just tried it on my full version, and it failed with a RTE, so it's a step in the right direction.

As for the debugging, at first I thought "debug.print!", but then thought..."how am I going to see it?"
The logger idea is good, I've got one, but what a pain to add/modify.
First, I thought I'd see if anyone else is having this problem with a big code set.

[twgonder]

Okay, I first thought I'd try msgbox idea, and it worked good.

Here is the offending code that normally closes the Navigation pane (I picked this code up in some forum)

 DoCmd.SelectObject acTable, , True
 DoCmd.RunCommand acCmdWindowHide

Assuming that code is good for closing the Navigation pane, but it fails in runtime (probably because there isn't one?),
the question now turns to knowing if we are running a Runtime file, for an IF statement.

(It's odd that that code sometimes ran fine in Runtime, and at other times failed with an RTE)

[twgonder]

Chat GPT came up with this code:

Sub CheckRuntimeMode()
    If CurrentProject.FileFormat = acRuntime Then
        ' Your code for .accdr (runtime) mode here
        MsgBox "This database is running in .accdr (runtime) mode."
    Else
        ' Your code for regular .accdb (design) mode here
        MsgBox "This database is running in design mode."
    End If
End Sub

Has anyone run into these kinds of problems with other code that fails in runtime mode?
Are there any modes other than acRuntime that need considering for a more robust Sub?