none
Microsoft Access Crashing. Microsoft Access has detected that this database is in an inconsistent state RRS feed

  • Question

  • I work for a small business and we have a Microsoft Access database that is shared and used by all office users. We have about 10 users.

    The database is split into a backend and a frontend. Backend is on the server and the frontend is on each users PC. All data is in the backend and the forms, queries etc in the frontend.

    Occasionally, the database will stop working and when you try and open up a form, you will get an error message saying that the database is in an incorrect format. Everyone must then close down the database and the backend needs to be repaired. When you open the backend, you get this message "Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database. During this process, a backup copy of the database will be made and all recovered objects will be placed in a new database."

    Clicking OK will repair the database and the users can carry on like nothing happened. There is never any data loss and nothing is placed in the "Recovery errors" table.

    This has been happening for a number of months and i cannot find a cause or solution. It sometimes goes a couple of weeks without crashing, sometimes it crashes a few times a day.

    I am using Access 2016 but the problem existed in previous versions.

    Does anyone know how i might fix this? Thanks

    Thursday, April 13, 2017 8:37 AM

Answers

  • It's hard to say what causes a hanging lockfile. Most often it's a hiccup in the network, as mentioned above. It can also be caused by someone using the power button to restart their system.

    If the hanging lock only happens sometimes, I'd be more inclined to think or network issues.

    And, again - be sure everyone's workstation is up to date. You'd be surprised how often you think they are, but when you check you find numerous failed updates. 

    One more thing - is everyone using the same version of Access/Office? While this did not impact earlier versions, the more recent versions of Access seem quite a bit more picky about this.


    -- Scott McDaniel, Microsoft Access MVP

    Thursday, April 13, 2017 2:22 PM

All replies

  • Corruption is most commonly caused by dropped or flaky network connections. Run tests on your network to ensure that you have no bad/faulty hardware (NICs, routers/switches/ cables, etc). 

    If users are connecting over a wireless connection, then don't do that. Wireless connections inherently drop/reconnect, and that can wreak havoc for an Access database.

    Make sure you've set Permissions for the Backend folder correctly. All users must have read/write/create/destroy permissions on that folder. A simple way to test is to try and create, update, and then delete a Text file in that directory from each user machine. If you can do that, then in most cases your permissions are set correctly.

    Also, have everyone log out of the database, and check that Backend folder to ensure you don't have a "hanging" lock file. Access produces a lock file when the first user opens the database and will delete that lock file when the last user closes the database. If the lockfile remains after the last person is out it can sometimes confuse the locking mechanism, and you could end up with inconsistent locking. To resolve that, after everyone is out of the database delete any files ending in ".ldb" or ".laccdb". If you cannot delete those files, you may need to restart the machine.

    Finally, be sure that Office and Windows are fully updated on each workstation.


    -- Scott McDaniel, Microsoft Access MVP

    Thursday, April 13, 2017 12:24 PM
  • Hi typicalex1

    Are you running on Wi-Fi?

    My experience, and others, says don't. Run FE/BE on cable.


    Best // Peter Forss Stockholm GMT +1.00


    Thursday, April 13, 2017 12:57 PM
  • Corruption is most commonly caused by dropped or flaky network connections. Run tests on your network to ensure that you have no bad/faulty hardware (NICs, routers/switches/ cables, etc). 

    If users are connecting over a wireless connection, then don't do that. Wireless connections inherently drop/reconnect, and that can wreak havoc for an Access database.

    Make sure you've set Permissions for the Backend folder correctly. All users must have read/write/create/destroy permissions on that folder. A simple way to test is to try and create, update, and then delete a Text file in that directory from each user machine. If you can do that, then in most cases your permissions are set correctly.

    Also, have everyone log out of the database, and check that Backend folder to ensure you don't have a "hanging" lock file. Access produces a lock file when the first user opens the database and will delete that lock file when the last user closes the database. If the lockfile remains after the last person is out it can sometimes confuse the locking mechanism, and you could end up with inconsistent locking. To resolve that, after everyone is out of the database delete any files ending in ".ldb" or ".laccdb". If you cannot delete those files, you may need to restart the machine.

    Finally, be sure that Office and Windows are fully updated on each workstation.


    -- Scott McDaniel, Microsoft Access MVP

    All users connect over ethernet. Permissions are all set correctly and there is sometimes a .laccdb file left over after everyone is logged out. But this keeps on happening and need to find the cause of it.
    Thursday, April 13, 2017 1:54 PM
  • It's hard to say what causes a hanging lockfile. Most often it's a hiccup in the network, as mentioned above. It can also be caused by someone using the power button to restart their system.

    If the hanging lock only happens sometimes, I'd be more inclined to think or network issues.

    And, again - be sure everyone's workstation is up to date. You'd be surprised how often you think they are, but when you check you find numerous failed updates. 

    One more thing - is everyone using the same version of Access/Office? While this did not impact earlier versions, the more recent versions of Access seem quite a bit more picky about this.


    -- Scott McDaniel, Microsoft Access MVP

    Thursday, April 13, 2017 2:22 PM
  • It's hard to say what causes a hanging lockfile. Most often it's a hiccup in the network, as mentioned above. It can also be caused by someone using the power button to restart their system.

    If the hanging lock only happens sometimes, I'd be more inclined to think or network issues.

    And, again - be sure everyone's workstation is up to date. You'd be surprised how often you think they are, but when you check you find numerous failed updates. 

    One more thing - is everyone using the same version of Access/Office? While this did not impact earlier versions, the more recent versions of Access seem quite a bit more picky about this.


    -- Scott McDaniel, Microsoft Access MVP

    I can confirm no one is restarting their system.

    This happened before we upgraded to Office 365 (2002 previously) so i'm inclined to think there is an issue with the backend or a problem with the Network. Not the simple fix i'd hoped for.

    Thanks

    Tuesday, April 18, 2017 11:57 AM
  • I know this is an old thread but i did eventually solve my problem. I am updating this as there are many people with this problem and the answer is very difficult to find.

    The answer is here.

    Snippet:

    The solution here is to leave SMB2/3 enabled but disable leasing.  Leasing is just an enhanced form of OpLocks.

    Here is the registry entry that needs to be added to disable server leasing for SMB2.1.  You will need to reboot after setting this entry.

    Key:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
    Value:  DisableLeasing
    Type:  DWORD
    Data:  0x1

    Wednesday, January 17, 2018 3:05 PM
  • Can you tell me - is this registry change done on the 2012 server, or on the user's workstations that access the database, or both?
    Wednesday, September 26, 2018 1:02 PM
  • On the server.
    Thursday, September 27, 2018 8:56 AM