Access Database is getting corrupt again and again

Thanks mgnagle - Sounds like a good solution, but I'm not allowed to make registry fixes on users' laptops, which is why I'm trying to contact the right IT Support Dept in my company (Huge company). Once I can discuss your and others' fixes with this dept, I can get it reviewed, tested and implemented.

What are your thoughts on Access 2013 users still accessing an Access 2016 database, while mostly Access 2016 users are accessing the same database concurrently (backend db is on a network) ? Can this situation causing data corruption issues also ?

Some of the speed problems reported here are not caused by this fix - they are just bad programming practices and are muddying the waters, preventing a genuine fix being adopted. 

Well, what can I say ?

Did you see any sample codes of this bad programing to share with us ?

But lets say you are right. And there is a bad programing with dlookups inside queries etc ...

Why with Server fix, this "bad programing" is performing faster than in client fix.

Doesn't this means that there are some speed issues with the solution of client fix ?

PS

Have to say that client fix is definately a fix and is working perfectly, just like the server fix.

And I personnaly insist that in many cases, described above, including JDBC connections, client fix is having speed issues and not always with bad programing. But if if works for you ... it is ok

Hi George!

With a split database, I thought it was always best practice that everyone is using the same version of Access.

Regarding our database, we identified the string of queries/macros that were working just fine before the Microsoft update, but now would produce the inconsistent error, if the user initiating this was not the first one in the database. 

SO, we setup procedures so that before this set of queries/macros was initiated, all users' sessions would be closed, and the user initiating the process re-opened.  Others would be prevented from logging in until the process had completed.

Since it is something done usually first thing in the morning, it has worked out without much disruption.

There may be an occasional inconsistent error, but the above has remedied 95% of the problem for us.  (Use to be years between inconsistent errors)

Still looking for a resolution from Microsoft.  If anyone knows where or who we could send a split database sample, it demonstrates the issue as often as they would like to perform it.

Can you give us examples of the types of queries that are associated with the problem?  That would be most helpful.

The queries were delete or update queries to tables in the backend that would generate the error.

But the issue appeared to be when a certain threshold or number of such queries in succession was executed. Using DoEvents or other delay procedures did not make any difference.

1. The initial test where the one to initiate the queries was not the first user in, the error would always hit on the same query.
2. If that query was skipped the next query would cause the error.
3. The group was than divided into three separate groups. 

  Any one group by itself would work fine.  But any two would produce the error.

Other notes:  (Some of these were noted in a previous post)

4. If the user was the first one in and others were logged in, the set of queries/macros would work fine.
5. If another user was logging in while the queries/macros were running, it would produce the error.
6. If the LBDviewer was used to see the users, the advantage of being the first user in seemed to be lost; ie if they initiated the queries/macros after the LBDviewer was used, it would produce the error.

All these scenarios could be reproduced over and over.