What happens to back-end ACCDB/LACCDB when a user closes the database?

    General discussion

  • Access 2010. I need to know exactly what MS Access does regarding the back-end LACCDB file when a user closes the front-end.

    Obviously MS Access must somehow check if the user closing it is the last user logged-on since it must then delete the file and if this is the case, it must check the file permissions to check if this user has permissions to do the delete.

    If the user is not the last to close, MS Access must update the LACCDB file after checking that the user has permissions to do the update.

    Does anyone have more detailed information or know if anything else happens regarding the LACCDB file permissions.

    Friday, August 29, 2014 2:25 AM

All replies

  • If you share mdb.accdb file on file server the db file must be in folder where user have read, write, create, and delete privileges.

    If user don't have correct privileges on folder, that is your problem not access

    After closing Access don't update info in lock file.

    laccdb corespond to ldb file see this:

    Introduction to the Access 2007 file format

    Introduction to .ldb files in Access 2000

    Introduction to .ldb files


    Friday, August 29, 2014 5:53 AM
  • Surely the LACCDB file is updated when a user closes the database because viewing the LACCDB file tell you whether a user is logged on or not?

    My evidence from tests I have run is that MS Access is changing the permissions on the LACCDB file when a user closes the database.

    I have read all the articles you gave but there is nothing specific to LACCDB files and this is a completely different database engine.

    Friday, August 29, 2014 6:31 PM
  • From my first link:

    .laccdb    When you open an Office Access 2007 database, file locking is controlled by a locking file with the file name extension .laccdb. The .laccdb file corresponds to the .ldb locking file that is created when you open an earlier version Access (.mdb) file. The type of locking file that is created depends on the file type of the database that is being opened, not which version of Access you are using. For example, if you open the file Db1.mdb, Access creates and opens a file named Db1.ldb. By contrast, if you open the file Db1.accdb, Access creates and opens a file named Db1.laccdb. Locking files are deleted automatically when all users close the database.

    So info about ldb files is what you need.

    If you want determine who is logged to db, You can not rely on information from lccdb file, you must use jet UserRoster, Also work with the newer version of access....


    Friday, August 29, 2014 7:31 PM
  • My evidence from tests I have run is that MS Access is changing the permissions on the LACCDB file when a user closes the database.

    Like to see this evidence.

    AFAIK, .lccdb keeps a log table of connections for instance

    • Entry A, ComputerName, UserName
    • Entry B, ComputerName, UserName
    • Entry C, ComputerName, UserName

    When A and B log entries are erased or the link is killed the .lccdb stays open because the log table is not empty. When C also is killed, then the log is empty and the Auto shutdown runs. This is true no matter which log entry is killed last just that the last one does not cancel the close action.

    Similar code can be made in your apps like using the Detect Idle Form to auto close your app when there is no activity for a set time length. (If you want that I can post it here). The point is that there does not have to be any manipulation in the .lccdb for it to continually check the log and when empty shut down. Contrastingly if your app closes unexpectedly the connection still exists in the log so the .lccdb file cannot close.

    There are certain circumstances especially over WIFI networks that can cause an .lccdb file to get corrupted. It is probably important to know that the only real function of the .lccdb is to attempt to maintain a connection between databases. It does not verify users nor does it verify permissions.

    Just takes a click to give thanks to someone whose post helped or answered your question. Please vote “Helpful” or Mark as “Answer” as appropriate. Chris Ward - Microsoft Community Contributor 2012 Award

    Friday, August 29, 2014 8:35 PM
  • I just proved this again a few hours ago. Either MS Access or Windows is changing the LACCDB file permissions.

    User A opens the database FE, BE LACCDB file permissions are viewable and look fine.

    User B opens the database FE, BE LACCDB file permissions are viewable and look fine.

    User B closes the database FE, BE LACCDB file permissions are unviewable (even by domain admin)

    NOTE: This does not happen if actions of user A and user B are reversed i.e. no problem occurs if user B opens database first.

    Friday, August 29, 2014 9:15 PM
  • I think only MS Access/Jet team know what access do with laccdb file, of course we can try to prove our assumption...

    But if I want check who lock/use database I base on manual. ldb/laccdb file that is internal mechanism db. Maunal "says" use jet UserRoster...

    Ok, you can check behawior db engine, but only product developer from MS can you give correct answer.



    Friday, August 29, 2014 10:13 PM
  • The file is likely inheriting permissions form the user that FIRST opened the database and created the locking file. In fact as pointed out it windows permissions that doing this and not Access. It thus sounds like individual permissions have been assigned to individual users for that folder (not a good idea).

    So I can’t see how users closing Access will change permissions on the file, but I can certainly see how the first user in who creates the locking file could well have specific permissions assigned when that locking file is created by the first user in.

    On exit, if last user out, then the locking file is simply deleted, but as your screen cap shows that not going to happen when last user out does not have permissions to delete that file.

    And if additional users that attempt to open the file cannot open the locking file, then such users likely will open the data file as read only since the multi-user locking file is required for multi-user operation. If users cannot open or create the locking file then users will likely open the file in read only mode.


    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, September 02, 2014 10:44 PM
  • Thank you for your insights.

    I have still not been able to resolve this problem for this group of users.

    The problem still remains that when one of this group of users is the first to open a database (and thus creates the back end LACCDB) then after any subsequent user closes the database, the back end LACCDB immediately becomes locked to new users. Multiple existing users who already have the database open can continue to work but any new user who tries to open the database gets the 'file in use' message. It is definitely someone closing the database that triggers the issue.

    Since I have reproduced the problem in two different folders with two different databases, I do not believe it is related to either the folder or to the database but is related to the group of users first opening the database (the Windows file owner).

    I have worked with our Security department and our Desktop Support department to modify the permissions and the users's profile but nothing has helped so far.

    I am open to any further suggestions as to how to diagnose this problem. I have worked on this on and off for almost 2 months and have just about run out of ideas.

    Wednesday, September 10, 2014 7:27 PM