Runtime error after splitting database

[artlaw]

This behavior bothers me the most. It ALMOST seems to indicate that you must have "side effects" in your code that initialize things as you go, and that because of error handling, the Runtime version doesn't catch the errors correctly. In this context, I use "side effects" to mean that something attempts to update a global variable after the code has started, and something about the error handling or external references is handled differently between Runtime vs. full Access.

I'm not going to swear this is your problem, but that description makes me think it is happening that way.

Do you have something that late-binds some definitions or something like that?

EDIT: Second question: Does this "stepwise" improvement occur as you make these tries in the same session? If so, do you get that stepwise improvement if you log out and log back in between failures?

Yes, this is what I thought was the strangest behaviour too. Once I have stepped through the various errors and it becomes stable, it remains stable. Even if I restart the computer. It is only when I delete the database and open up a new copy that it throws the errors again.

I will look through my code and check how the global variables are handled (there are only two) and also any late binding. Would there be a reason that these would be OK when the database is just one part, but then become troublesome once it is split? That also seems really strange to me.

 

[artlaw]

Hi all,

Hopefully someone out there is still monitoring this thread. I have some additional information that may be of use.

I thought I would start fresh and see the absolute minimum features required to trigger this error... the results were pretty crazy.

1. I created a new database with a single table in it called tblNames. The table had two fields - the default auto increment ID index field, and a short text field called FirstName.
2. I created a form called frmNames using the wizard based on the table tblNames.
3. I moved the database to two separate test computers with the Access runtime installed. One computer was a work computer (with reasonably strict security measures) running the 32-bit version, the other computer was my home computer running the 64-bit version, with a clean install of Windows 10, full admin rights and absolutely no special security measures (not even anti-virus software).
4. The complete database worked OK.
5. I then split the database on the development computer using the wizard, updated the linked table paths (appropriately for each test computer), set the form as the default form to open and tried again.
6. Both computers threw a -3034 runtime error and crashed.

This test database was a simple as they come. No queries, no VBA, nothing complicated at all. Running the test on two computers (with varying security measures) eliminates some kind of operating system setting. It seems to me that the issue is with the Access runtime. I am completely at a loss - has anyone else been able to replicate this issue? It doesn't trigger if I run it on the development computer even when run as runtime. I think it only happens when it is the actual runtime version (i.e. no full version of Access installed).

 

[moke123]

post a copy

 

[artlaw]

Here is the database. The linked table reference will need to be updated in Access prior to running on the runtime version.

 

[moke123]

I didn't see anywhere in the thread where you describe the versions of access your using and what version of runtime your using.

3. I moved the database to two separate test computers with the Access runtime installed. One computer was a work computer (with reasonably strict security measures) running the 32-bit version, the other computer was my home computer running the 64-bit version, with a clean install of Windows 10, full admin rights and absolutely no special security measures (not even anti-virus software).

Am I reading this correctly that you are running both 32 bit access and 64 bit access?
Could you clearly describe both set ups?
What version(s) of runtime your using?

 

[artlaw]

I didn't see anywhere in the thread where you describe the versions of access your using and what version of runtime your using.


Am I reading this correctly that you are running both 32 bit access and 64 bit access?
Could you clearly describe both set ups?
What version(s) of runtime your using?

1. My development computer is running Windows 10 with Microsoft Access 365 MSO (16.0.13426.20330) 64-bit.
2. The first test computer is running Windows 7 with the Microsoft Access Runtime 2013 32-bit (15.0.4569.1506). The version of Microsoft Office installed on this computer is also 32-bit.
3. The second test computer is running Windows 10 with the Microsoft 365 Access Runtime 64-bit version installed from the link below. There is no Microsoft Office installation on this computer (https://support.microsoft.com/en-us...-runtime-185c5a32-8ba9-491e-ac76-91cbe3ea09c9)

 

[gemma-the-husky]

I've not been logged in for a while.

However, the error handler in form_open just displays an error, and then resumes.
You can't assume it's safe to do that. The underlying reason for the first error might be leading to many other errors.
You might even be getting unhandled errors in code AFTER the form_open completes.

It may be an issue with using the same code with 2 versions of access in different bitness.
Besides the bitness, if both users are using the same .mdb/.accdb then it might be that the O365 64bit version is making changes to the database, that then cause the 32 bit runtime to fail.

You really need to make sure you give each user a personal copy of the front end, and not have multiple users sharing the same front, even if not concurrently.

That's what we always recommend.

 

[artlaw]

Hi Gemma, thanks for your reply. As per my post at #22 I have managed to replicate the error with the most simple database - a single table, single form, no VBA and no queries. So I can safely say that the trigger isn't VBA code. Also, both test computers that I am running it on have entirely independent installations for now - the front end and back end sitting on the respective desktops (i.e. back ends are not on a server and cannot be accessed by both users). So one can't be making changes to the other. Once I have the issue resolved I will be moving the backend to the server, and distributing the front end to all users. It seems to be the runtime installation that is causing this error.

 

[CJ_London]

machine 2 per post 26. What version of office is installed? and does that version include Access? If so, have you tried running your app from the full version?

You are aware you are developing in a later version of access that the runtimes? Like most apps, access is not backwards compatible. You say you used the wizard to create the forms - that may have introduced a feature not available to 2013 version.

So a few things to try

1. design you own form, rather than using the wizard, keep it simple
2. try saving your app as an earlier version, or develop in an earlier version
3. try installing office 365 runtime on your test machines - https://support.microsoft.com/en-us...-runtime-185c5a32-8ba9-491e-ac76-91cbe3ea09c9

 

[gemma-the-husky]

It really is difficult with a runtime version as by it's very nature you can't trace code execution. You could put a load of temporary message boxes in to show the start up actions. It might be something else though.

Can you check the references libraries being used in the code editor. If they aren't right, or don't exist on different machines you can get all sorts of spurious errors in the database operation.