Access Database is getting corrupt again and again

Wow!  Thanks for the detailed answer.  I'm going to study this and check my app for any of those conditions.  I did modify all the update queries after the query error fiasco but this is a different scenario.

I began outlining the list of every query and its type from these procedures and macros in their order to further study this conundrum.  There are dozens, so hopefully over the next several days I can work thru this and test to see if any other patterns can be discerned.

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.

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

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.