Access Database is getting corrupt again and again

Thanks for the answer..

Of course I will try it.

If anyone else is experiecing performance issues, please share with us.

Hi Theodorus (and others still struggling with this),

I cannot exactly answer your question, but I'm puzzled why you and others have apparently not tried the variation detailed by Mark Mauger on November 29th (the last post on this date, on page 26 for me). It sounds fairly simple to test, but no-one has reported back as yet. Maybe it will not suffer the same performance issue?

Luckily my clients have eventually been able to disable leasing on their servers and have not reported any performance issues as yet.

Good luck!

Sorry for asking but I am still a bit confused. 

Up to now we have:

1. The SMB cache solution that can be applied on client machines and resolve the issue

Or

2. Apply the disable leasing fix on the server, without applying the SMB cache solution on each client pc

So I kindly ask you to tell me your experiences with performance of each solution. I experience with Disabling Server leasing solution, serious lack of speed when executing action queries and dlookups from windows 10 clients. With windows 7 clients there is also lack of speed but less important. Is the solution (1) that is applied on each client machine faster? Are you experiencing same speed problems?

Please MS don't abandon us..

Thanks MarkMauger!

I likewise have developed this app for over 2 decades and it would take years to reproduce in a new code/database.

1. Finding the time to develop a sample that would duplicate the issue is complicated.
2. I need to look more closely at the list of the delete and edit queries and try to understand why it appears when it reaches a certain number of these, that it will go no further without the inconsistent issue.  Anyone have any ideas about this?

Regarding what I recently tested.

3. It seems very interesting to me that if the user who is going to initiate the morning updates, is first in, they will have no problem completing the task without the inconsistent issue.  But if they are second or later, then it will create the issue.

SO question: Is there some advantage or difference about being first in the ldb file that prevents the inconsistent issue?

4. If I verify how using the ldb viewer somehow negates the advantage of being in first, then what is up with that?
5. Unfortunately for me, the ldb file is a "black  box". I have now idea how it works with keeping track of locks or what else goes on in this file other than the computer and user names.  I would ask a lot of questions, but maybe this is not the thread for that.

This week we hope to have IT install the workaround on the new server to test further and ensure it solves the inconsistent issue and see how it affects performance.  But I would prefer trying to figure something out in Access that can side step the issue altogether and keep the benefits of leasing on the server.

Thanks!

Hi ShondaH1 !

Likewise have code in place that will close a session after an hour of inactivity after 3pm and then another closing all sessions after 11pm.  And I also have a custom compact utility that will close out all sessions automatically. Unfortunately there are a few situations that prevent the session from closing down.

1. If there is an unmonitored open dialog box, it will hang here.
2. If someone else logs into the computer while the frontend is open for the previous person, it will not close.
3. If the computer goes to sleep before the session has ended.

Compacting the database to get it back after an inconsistent issue, is complicated by sessions that keep the ldb file open.

As a last resort I use the ldb viewer, locate the computer and have it restarted.