Access Database is getting corrupt again and again

Hi Tom  I am amazed you are still touting the disableleasing on the server as the solution - it has been pointed out here many times that (1) it requires administrator access to a server that in many cases is a shared resource used by numerous other departments in an organisation, and (2) it is a  "FIX" that is known to cause serious side effects for speed on some servers.  It is not a viable solution.

So why is it still being rolled out here again. The simple Windows 10 CLIENT SIDE reg fix provided here 9 months ago works in every case and requires only local privileges on the Windows 10 Client. 

The disableleasing on the server is not a solution and has too many caveats and side effects.

Has anyone found this not to be the case?  Please post if you have applied the Client side fix and it has not worked.

I agree this client side change works and may very well have saved my business. The next important question is has anyone experienced any negative side effects to the database in question or any other applications or Windows itself after making this change? I do like this approach because I do not have control of the server configuration.

So the best advice to everyone. Make this change now to ALL Windows clients involved (and reboot) and your problems should cease. That is a until a new Windows 10 client without the change is introduced or the registry change gets overridden.

The server side change to one share I suggested has appeal if you have control of the server. Change just one place and it does not matter what the client side looks like.

Having said all that, Microsoft has to fix this. We should not have to go through this pain or have to apply these band aids. And who knows how long they will last. We have some fixes, but we need leadership from Microsoft to do ROOT CAUSE ANALYSIS and permanent CORRECTIVE ACTION. Basic problem solving technique.

Is Microsoft even listening anymore?

There was a noticeable performance issue on one  Windows 10 machine that I applied the fix to.

I had applied the fix proactively assuming that all Windows 10 computers were affected. Since this turned out not to be the case, i was able to revert the changes without experiencing the issue.

Ultimately i only needed to apply the fix to two machines to eliminate the problem.

To those who do not understand why the server side work around is still vital:

At many organisations the client configuration is also strictly controlled by IT departments. Only IT can "legally" apply any such Registry change, so it is up to them which solution(s) they try. In many cases, they will only try solutions recommended by Microsoft. Moving the back end to another folder, or even to a spare PC, in many cases will not require IT department approval, or such approval will be easy, so further test reports on this approach will be valuable. IT staff unwilling to disable leasing on a whole server, or to disable caching on multiple clients, may be willing to disable leasing on a single share used only for the back end, so test reports on this will also be valuable.

I hope that helps to clear up the confusion.

I agree, David. Trying to get a fix installed on a host server or on all client machines require multiple levels of approval at my company. That is if IT Support is even willing or responding. This is not the case at my company, and frequently, you are left to find your own solutions. That is why I finally stumbled upon moving the BE database to another folder, relinking the BE tables to the FE data and setting the "Compact and Repair upon Close" option.

This is a quick, easy fix which worked for me, and I am in full control of. If you have to deal with multiple levels of company bureaucracy, try this first. If you are in a smaller company where IT Support is always available & willing, go for the server fixes mentioned previously.

Correction: relinking the BE tables to the FE database...