Access 2016 database crasing after 2019-01-29

[peraccess]

Has developed an Access system for a company that has worked since 2000. First it was access 97 which then upgrade to access 2003, access 2013 and now to access 2016. Meanwhile, the company has also upgraded Windows server. Today, Windows server 2016 is running. Meanwhile, Windows has also been updated and Windows 10 is now running.
Office runs as 32 bit.
The system has worked very well during these 19 years until 2019-01-29.
It has, of course, been under development and updated during all years.
In production, the system is run around the clock and has done so for 19 years.. Registrations occur throughout the day.
But now in 2019, the operating system was upgraded from Windows 7 to Windows 10 and Office 2013 to Office 2016. This didn't happen on all computers at the same time. But now all computers in the department have been upgraded.
The system thus went blameless until 2019-01-29. Then the first crash occurred. After this, the system has crashed about 3 times a week. The crashes seem to happen randomly and do not depend on how many people are in the system at the same time.
2019-04-01 I entered a log function in the system's error management. It shows crashes/errors since then. see below.

ErrorTime, Host, ErrorNummer, Sub/Function,
Error description
2019-04-02 12:22:58, XPC201, -2147352567, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-02 12:23:15, XPC201, 3343, KOLL_POÄNG, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-02 15:37:01, XPC159, 3043, LIST_Click, Network access canceled. Close and open the database again ...
2019-04-02 15:37:44, XPC159, 3043, Form_Unload, Network access canceled. Close and open the database again ...
2019-04-03 05:10:14, XPC159, 2501, UTS_Click, The OpenReport instruction was canceled.


2019-04-04 13:49:00, XPC197, 3343, Form_Activate,Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:49:06, XPC197, 3343, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:49:11, XPC197, 3343, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:49:56, XPC197, 3343, Form_Activate,Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:50:02, XPC197, 3343, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:50:05, XPC197, 3343, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:50:41, XPC197, 3343, Form_Activate,Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 13:50:44, XPC197, 3343, Form_Unload, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-04 14:24:38, XPC159, 3024, UTlogg_Enter, The file 'SELECT AnvID ......' cannot be found
2019-04-04 14:25:59, XPC207, 3078, Form_Unload, The table or question cannot be found USERLOGG
2019-04-04 15:13:53, XPC159, 3078, AID_LostFocus,The table or question cannot be found USERLOGG
2019-04-04 15:14:00, XPC159, 3078, INLOGG_Click, The table or question cannot be found USERAVD
2019-04-04 15:14:03, XPC159, 3078, AID_LostFocus,The table or question cannot be found USERLOGG
2019-04-04 15:14:12, XPC159, 3078, AID_LostFocus,The table or question cannot be found USERLOGG
2019-04-04 15:14:19, XPC159, 3078, Form_Unload, The table or question cannot be found USERLOGG
2019-04-04 15:59:15, XPC206, 3078, Form_Unload, The table or question cannot be found ComputerInDB1
2019-04-04 20:32:05, XPC159, 2501, UTS_Click, The OpenReport instruction was canceled
2019-04-07 15:07:29, XPC159, 3343, UppdatReg, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-07 15:07:35, XPC159, 3343, LäggIn_Poäng, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'
2019-04-07 15:07:37, XPC159, 3343, TyngdNU, Unknown database format '\\aaaaaa.bbbbbbbbb.se\cccc$$\DB1.accdb'

The database is running with a shortcut pointing to the database. the shortcut is fictitious but the same format as it says in the Error log above.
The change made when the errors started is that the IT department put Windows 10 and Office 16 on the department's computers.

Would be grateful if anyone could solve this problem. The system is important and is used all the time.

Access developer

*sorry but i have post this at https://www.utteraccess.com/forum/in...wtopic=2053336
and https://answers.microsoft.com/sv-se/...=1554805538119

But i am in great need of help

[ranman256]

What is crashing? The Frontend? The backend?

I have seen this on a PC we had because it got upgraded and NOTHING I did would stop it from crashing.
I moved it to a Pc that was not upgraded and it worked fine.

[peraccess]

Exactly the same database where only data separates these is located on another department that runs windows 7.
The database works great there.
So I wonder if it's windows 10 or can there be any change that the IT department made.

The database is not split

[JoeM]

We had a situation like this where people were being converted to new computers and versions of Office at different times. So some were still using old, while others were using new. We had tons of crashes.
Then we discovered that if you have multiple people using the same database, you need to split your databases into a separate front-end and back-end, and each user should have their own copy of the front-end to run.
When we did this, the crashing issue went away.

Regardless of whether or not users are on different versions of Access, it is very strongly recommended that all databases be split, and each user uses their own copy of the front-end. This eliminates most crashing problems.

In the event that an Access database becomes corrupt and cannot be fixed, we have had great success creating a new blank Access database, and then Importing all objects from the old one to the new one, and then using the new one.

One last thought, if people are on different versions of Access, I think it is best to do all development on the back-end and front-ends in the oldest version of Access (until everyone is upgraded). That will decrease the changes of issues (i.e. using a new feature, function, etc that the old versions cannot understand).

[peraccess]

Crash :
If you try to open the database after errors have occurred, an Access error message will appear that the database is in an inconsistent state. Access then wants to create a backup and try to recreate the database.
This usually succeeds but the problem remains.

[JoeM]

This usually succeeds but the problem remains.

See what I said above:

In the event that an Access database becomes corrupt and cannot be fixed, we have had great success creating a new blank Access database, and then Importing all objects from the old one to the new one, and then using the new one.

And make sure you do it in the oldest version of Access anyone might still be using.

[pbaldy]

Have you tried:

https://www.devhut.net/2018/06/13/ac...gnized-format/

[peraccess]

I definitely think this problem does not matter if the database is split or not. Look at the error list.
The database has worked for 19 years without crashes

[JoeM]

I definitely think this problem does not matter if the database is split or not. Look at the error list.
The database has worked for 19 years without crashes

Regardless, it is HIGHLY recommended that if you have multiple users using the same Access database you should ALWAYS split the database.
Not doing so is begging for trouble, sooner or later. If you have gone 19 years without issues, count your blessings, but it is ill-advised not do so going forward.

You would be hard-pressed to find any knowledgeable Access programmers who would advise otherwise. It is listed as a best practice, and for good reason. Many of us have found out the hard way.
Take a look here, especially at reasons 1 and 13: https://www.techrepublic.com/blog/10...cess-database/
There are plenty of more articles saying the same, that you can find with a simple Google search.

[Micron]

I definitely think this problem does not matter if the database is split or not. Look at the error list.
The database has worked for 19 years without crashes

I understand that train of thought. Unfortunately, upgrades can make what was an OK situation not OK anymore. While splitting may not have been an issue in the past (aside from the point that it's advised) not doing so may no longer be viable after an upgrade. However, as you've probably seen from one of the other forum answers, the issue isn't new and one solution seems to be rolling back to an earlier Windows update.

[peraccess]

Have you tried:

https://www.devhut.net/2018/06/13/ac...gnized-format/

Thanks ! This make sense.