Inconsistent State, unable to open backend
- Thread starter mjdemaris
- Start date
- Local time
- Today, 12:57
- Joined
- Aug 30, 2003
- Messages
- 36,269
- Local time
- Today, 14:57
- Joined
- Feb 28, 2001
- Messages
- 30,046
Yes, but not this one. Using queries for all forms, even if they are "single table" queries, helped me with sharing issues. Also, I never found out why, but when I started, I was using forms directly to tables and I kept on getting pop-ups from Access wanting to know where to find the table in question. When I switched to queries to drive my forms, that problem went away cold. Never saw it again. But never found out the theory of why it did that.
This is a flare-lit tip-off that you were looking at a hung session. The network-layer time-out doesn't always clean it up right away, but the Windows Server systems have policy-based timers that forcefully abort idle sessions past a certain age. For instance, after 24 hours, a user process just shouldn't be there.
Once the session starts to die, the network connections go through something called "I/O rundown" that cycles through every handle in the process to shut down that handle's I/O path. The process cannot die until rundown completes, but when it DOES complete, all locks should be totally released. That you were able to delete the files after passage of time speaks to the probable "process rundown" timer at work.
The problem has arisen once again. I have not installed any timers, yet.
So, I will go through the process once again, however, I do need to find out why this happens.
Let's say Mark opens the DB, places a lock on the BE, first thing in the morning. He leaves the FE open most of the day.
Mike, Paul and Gina all use the DB off and on, without any problems.
Q1: Does Mark still have the lock? What does Access do if other users open the DB: it can't have 10 locked files...
Q2: When Mark closes his DB, who gets the next locked file, if it's assigned?
Doc: will a shutdown timer in the FE help prevent this "hung session"? It seems as if it might.
So, I will go through the process once again, however, I do need to find out why this happens.
Let's say Mark opens the DB, places a lock on the BE, first thing in the morning. He leaves the FE open most of the day.
Mike, Paul and Gina all use the DB off and on, without any problems.
Q1: Does Mark still have the lock? What does Access do if other users open the DB: it can't have 10 locked files...
Q2: When Mark closes his DB, who gets the next locked file, if it's assigned?
Doc: will a shutdown timer in the FE help prevent this "hung session"? It seems as if it might.
- Local time
- Today, 14:57
- Joined
- Feb 28, 2001
- Messages
- 30,046
MJ, a shutdown timer in the DB will work but you have to watch out for the case of a user with an open form that is dirty when they walk away AND you have confirmation software in place with an "Are You Sure" type of question. Because if the form is dirty and requires user confirmation, that puppy is LOCKED. EVERY FORM needs to test for a forced shutdown on a timer. In the most recent case where this was possible for me, I put an automatic Me.Undo followed by a DoCmd Close for the form. When the main form's timer detected that all forms had been closed, it was allowed to shut itself down.
If you ever find a user doing this trick of leaving a dirty form open all day, I strongly recommend summary execution by immersing the person in hungry nematodes in an inescapable container. Or just make them watch the move "Night of the Nematodes" - which can be described as "Not an A movie. Not a B movie. WAY below a C movie. I think we have to stop at Z movie 'cause nothing is lower."
As to the other question: Since databases HAVE to be opened in shared mode to allow sharing (well, duh!), Mark's lock is still there and so is everyone else's lock. And the DB doesn't have 10 lock files. It has 10 records in one lock file.
The lock file (.LDB) is always owned by the person who first opened it - because that person created it. But the folder's permissions allow ALL who have the appropriate rights to have MODIFY-level access. This includes Create File, Delete File, Read File, Update File, and a smattering of other detailed permissions. So it DOESN'T MATTER who created it. EVERYONE legitimately in there has Read, Write, Delete permissions automatically (if they can use it at all).
The way file locking works is that the File System libraries automatically look up the device's locks list. This list involves structures in the file's host's scratchpad memory. A file lock can be Exclusive Read/Write, or it can be Exclusive Write, Shared Read, or other combinations all the way down to "wide open with no protection."
The lowest level of lock is an "interest" lock that is used to notify the file owner. It is theoretically possible to write lock handler code so that if your program tries to get to a file, the file's current owner (holding the "interest" lock) can say YES or NO to your request. The presence of that "interest" lock is the mechanism that causes a program TRAP and the file owner's trap code can therefore be the "guard dog" for that file. But in the most common case, this extreme measure is NOT implemented.
The theory is that the host for that file is running the file system that must pass that file across the net, so the lock management on a network with file-sharing enabled is said to be "distributed." With the distribution based on the popularity and location of the files enabled for sharing, this is "Distributed Lock Management."
If you ever find a user doing this trick of leaving a dirty form open all day, I strongly recommend summary execution by immersing the person in hungry nematodes in an inescapable container. Or just make them watch the move "Night of the Nematodes" - which can be described as "Not an A movie. Not a B movie. WAY below a C movie. I think we have to stop at Z movie 'cause nothing is lower."
As to the other question: Since databases HAVE to be opened in shared mode to allow sharing (well, duh!), Mark's lock is still there and so is everyone else's lock. And the DB doesn't have 10 lock files. It has 10 records in one lock file.
The lock file (.LDB) is always owned by the person who first opened it - because that person created it. But the folder's permissions allow ALL who have the appropriate rights to have MODIFY-level access. This includes Create File, Delete File, Read File, Update File, and a smattering of other detailed permissions. So it DOESN'T MATTER who created it. EVERYONE legitimately in there has Read, Write, Delete permissions automatically (if they can use it at all).
The way file locking works is that the File System libraries automatically look up the device's locks list. This list involves structures in the file's host's scratchpad memory. A file lock can be Exclusive Read/Write, or it can be Exclusive Write, Shared Read, or other combinations all the way down to "wide open with no protection."
The lowest level of lock is an "interest" lock that is used to notify the file owner. It is theoretically possible to write lock handler code so that if your program tries to get to a file, the file's current owner (holding the "interest" lock) can say YES or NO to your request. The presence of that "interest" lock is the mechanism that causes a program TRAP and the file owner's trap code can therefore be the "guard dog" for that file. But in the most common case, this extreme measure is NOT implemented.
The theory is that the host for that file is running the file system that must pass that file across the net, so the lock management on a network with file-sharing enabled is said to be "distributed." With the distribution based on the popularity and location of the files enabled for sharing, this is "Distributed Lock Management."
RogerCooper
Registered User.
- Local time
- Today, 12:57
- Joined
- Jul 30, 2014
- Messages
- 546
I had a user with a similar problem, which we fixed by going back to Windows 7. There is a known, unresolved issue with this
Well, Doc, I haven't watched "Night of the Nematodes", yet, but I did find something that might cause a problem.
User A: opens program, opens form to create new purchase request
User B: does the same thing, about the same time.
A: begins entering line items on the sub form that he/she wants to order.
The subform's rec src is a query.
B: clicks a button on the request form to open a search form that allows User to add previous items to the current request.
This process copies the line items table to local FE, creates temp queries and tables to keep the data apart from the live BE.
After User B adds all the desired items, this data is then inserted back into the live Line Items table.
User A: the request is still open, and suddenly sees User B's line items on his request.
Also a probable situation, yet undetermined:
User B gets any committed line items from User A's sub form when the table is copied and the temps are made.
Does this cause an inconsistent state? Not real sure.
Could it? possibly?
I know that it does cause issues with the users, lol.
User A: opens program, opens form to create new purchase request
User B: does the same thing, about the same time.
A: begins entering line items on the sub form that he/she wants to order.
The subform's rec src is a query.
B: clicks a button on the request form to open a search form that allows User to add previous items to the current request.
This process copies the line items table to local FE, creates temp queries and tables to keep the data apart from the live BE.
After User B adds all the desired items, this data is then inserted back into the live Line Items table.
User A: the request is still open, and suddenly sees User B's line items on his request.
Also a probable situation, yet undetermined:
User B gets any committed line items from User A's sub form when the table is copied and the temps are made.
Does this cause an inconsistent state? Not real sure.
Could it? possibly?
I know that it does cause issues with the users, lol.
Similar threads
