Access Database is getting corrupt again and again

Well done, TQuasar!

With this kind of experimental data perhaps Microsoft could identify & finally FIX this problem.

Unfortunately, queries and their results are a basic part of the continuing operation in our database program.

Nearly every data entry (save / change /delete ) or record change involves queries to look up, compare, or be checked against filters and rules.

Your scientific comparison technique is a great step forward.

It really needs Microsoft to carry the ball from here.

I hope they contact you for more input.

I think they still read this blog, so I'm hopeful.

Best regards.

This reminded me of the ODBC connection pooling and connection time outs.  

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/odbc/dn170560(v=vs.85)

https://docs.microsoft.com/en-us/sql/odbc/admin/setting-odbc-connection-pooling-options?view=sql-server-ver15

Old post but possibly relevant.  https://www.techonthenet.com/access/queries/timing\_out.php

I am not sure if this will help you, or add to the rabbit hole.

Thanks TQuasar, this is very useful, detailed information. I will be checking my main queries this week.

George

We had about 36 queries, many update, delete and append queries. When it seemed to be a particular query we would test by having the process skip that query, it then just became corrupted on the next query.  

SO, we divided the queries into three sets, A, B and C. 

We tested and found that regardless of the order executed, either A-B-C or A-C-B or B-A-C or B-C-A or C-A-B or C-B-A

the corruption would always take place in the second set. It seemed that it was not the specific query that was the issue, but some issue which involved an accumulation affect, (maybe in some communication/network buffer?)

Now this corruption would only work when there were at least two in the database thru the network. (Though there were certain conditions when the corruption would not take place depending primarily on whether the one running the queries was the first one in the database.)

In any case, instead of using the workarounds, we worked it out so those processes would only be initiated with one person logged in, since it was just needed once in the morning.  This took care of 95% of the corruption issue; there would still be an issue once or twice a month.

NOW, for the past 5 months we have had no corruptions.  So, to test it, we allowed for the series of queries to be run with others logged in as well, and there is no longer a corruption issue.  (I assume there has been some Microsoft update, may be relating to networking, that inadvertantly has also corrected the corruption issue.)

It's unfortunate these type of people try to take advantage of people's pain/difficult situations. 

It happens far too often these days, especially during our current pandemic.