How do I delete Access lock files?

[TDunn]

I am just a gal that wanted to help my team track client activity. I know nothing about programming and most of what I've read here is like a different language. Using Google searches, I created a database, imported all appropriate files, created a Form, split the database, gave all team members their own copies, and we were off to the races. Now, all of a sudden, two out of the three members and the original FE have lock files that won't go away. I don't know what to do. Can someone please help me unlock these files and tell me how to prevent this from happening again?
To be clear, when I gave each team member their own copy, I saved them in a shared folder, they did not move them to the own machines. I don't know if that's the issue or not. I'm very confused.

 

[Jon]

Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!

 

[theDBguy]

Hi. Welcome to AWF!

When you close out of the FE, the lock file should automatically go away. Otherwise, any admin user should be able to simply delete them. You cannot prevent the lock files from showing up as their essential to how Access works. Even if they are still there, you can safely ignore them, sometimes.

 

[TDunn]

Hi. Welcome to AWF!

When you close out of the FE, the lock file should automatically go away. Otherwise, any admin user should be able to simply delete them. You cannot prevent the lock files from showing up as their essential to how Access works. Even if they are still there, you can safely ignore them, sometimes.

We can't ignore them as they prevent us from opening the files. We also can't get the administrator involved all the time or they will tell us to stop using the program. They're hateful like that. We need to know how to prevent it from happening. We don't know what we're doing wrong.

 

[Mike Krailo]

Why can't the user having the problem delete the offending lock file? Here is what the grand AI had to say about it.

• Ensure that users always open the database in shared mode, rather than exclusive mode, to allow multiple users to access the database simultaneously.
• Set control properties on forms to enable and lock data entry, preventing users from inadvertently changing data.

Resolution

• Check the lock files (.laccdb and .ldb) to identify which records are locked and by whom. The Access database engine uses these files to determine which records are locked and by whom.
• If a user opens a database with exclusive access, record locking is not used, and Microsoft Access doesn’t attempt to open or create a lock file. If the database is always opened for exclusive use, a user needs to have only read and write privileges to the folder.
• To unlock Microsoft Access record locking information, follow these steps:
  • Click on Options in the dialog box.
  • Choose the Advanced menu and select the “Default record locking” option.
  • Select the “No locks” option to unlock the record.
  • Click OK to finish the process.

By following these strategies, you can prevent and resolve stale lockfiles in MS Access, ensuring smooth and uninterrupted access to records.

 

[theDBguy]

We can't ignore them as they prevent us from opening the files. We also can't get the administrator involved all the time or they will tell us to stop using the program. They're hateful like that. We need to know how to prevent it from happening. We don't know what we're doing wrong.

I hope each user is using their own copy of the FE, correct? It doesn't have to be on their Desktop as long as they're not sharing the same physical file. Also, I hope you don't mean that your users are trying to open the lock file, right? The lock file (.LACCDB) is managed by Access. Users don't need to worry about it. You might need to describe your process step by step and provide screenshots if possible.

I also suggest you either post your question in the main forum or let me know if you prefer I move thread out of the Introduction forum.

 

[CJ_London]

We need to know how to prevent it from happening.

Make sure users close the app before switching off their computer or disconnecting from the network if that is where you have placed the FE's

 

[Pat Hartman]

Access creates the lock file when the database opens and deletes the lock file when the database closes. The primary reason that lock files don't get deleted is that the user does not have delete permission on the folder holding the application. You said you have given ever user a personal copy but in a shared server-side folder. Sounds like you gave each FE a different name. You probably should use the recommended method of having the users run the FE from their desktop. There are two basic methods. A distribution database and a batch file. I use the batch file because it is simple and obvious. There are several versions of a distribution database displayed here. Search for "batch file" and my name and you should see the 4 line batch file that I use along with an explanation of why I prefer that method.

That leaves us with the shared BE file. Your users will need permission to delete for that folder which is of course very dangerous. However, I think the IT people can set it up so that only the lock file can be deleted rather than the data file. But that leads to other issues. At least one developer or user need delete permissions on the BE folder because otherwise there will be no way to compact the BE since that process creates a new BE, copies everything into it, then deletes the original and renames the temp file it created. If you look in that directory and you see a slew of databasexxx. accdb files, that is what is happening.

 

[The_Doc_Man]

I'm going to repeat some of the advice given earlier, but in a different way.

In order to properly and safely share Access applications, you must develop them and then split them into front-end (FE) and back-end (BE). You keep your master copy of the FE in a safe and private place. You keep a current copy of the BE there so that you can develop in isolation from your users. You instruct the users to copy the FE file to their local computers and you build the "master copy" of the FE to point to the shared copy of the BE file.

Your users (and you, when NOT developing) need Modify permission on the folder containing the BE and on all files therein. For this reason, you MIGHT wish to put code in the "public" copy of the FE that would detect that it is running from the master distribution directory and make it not allow that. The Modify permissions on the files and their containing folder mean that your users can create, modify, and delete the lock file under appropriate circumstances. (Really, so Access can do that... but at the time, Access is running under the user's ID.)

Lock files in the user's working directory (where they keep the private copy of the FE) can be cleared by the user rebooting their workstation followed by just deleting the lock file. OR your user can go into WINDOWS TASK MANAGER and select the PROCESSES tab. Look for any active copies of MSACCESS.EXE. If they think they HAVE exited from Access but a copy is still floating around, that would be why they cannot delete the FE lock file. Windows file locking is still in the way because the task in question hasn't released the appropriate file handle.

If your users are capable, you can advise them (or help them) to open the CMD (command prompt) window, then navigate to that folder holding the offending lock file, and manually attempt to UNLOCK the file from a command-line prompt (CMD> UNLOCK filename). However, IF that fails, you might be in a situation that will lead to file corruption because in that case, Access might be in a state called I/O Rundown, which can ONLY be cleared by a reboot. And which potentially could lead to database corruption.

When the FE file is still open, its links to the BE are still open. That means the BE's associated lock file is ALSO open. You can type the contents of the lock file using NOTEPAD (but DON'T try to change anything, DON'T save any accidental changes...) There will be some machine ID numbers in the lock file that you can use to trace down who the BE thinks is still using it. However, if any user has incorrect permissions, the lock file usage becomes muddied and difficult to sort out.

The ultimate cleanup is a reboot of the server hosting the BE file, but this is radical and I can believe your IT person would hate you for too many reboots of a file server. Unfortunately, this reboot ALSO runs the (severe) risk of corrupting the DB file. Therefore, it would be better to find out who (which user) has the file locked. Once that person gets out of Access, all other locks should be easier to remove.

 

[gemma-the-husky]

If you just try to delete the lock file, windows will tell you the file is in use, and won't delete it. You can use administrator programs to see who does have active sessions on the back end database/lock file and kill those sessions. Then you will be able to delete the lock file.

As others have said, turning off a machine without closing access properly can result in the user not actually being able to resolve it himself, but the system administrator can stop the active processes. Without having to restart the server.

 

[Isaac]

I am just a gal that wanted to help my team track client activity. I know nothing about programming and most of what I've read here is like a different language. Using Google searches, I created a database, imported all appropriate files, created a Form, split the database, gave all team members their own copies, and we were off to the races. Now, all of a sudden, two out of the three members and the original FE have lock files that won't go away. I don't know what to do. Can someone please help me unlock these files and tell me how to prevent this from happening again?
To be clear, when I gave each team member their own copy, I saved them in a shared folder, they did not move them to the own machines. I don't know if that's the issue or not. I'm very confused.

WHY do you want to delete the lock files? I'm confused

 

[Gasman]

The FE should be on each users computer.
You *might* get away with a shared drive, if each have their own folder.

 

[GPGeorge]

Reading between the lines, I think this may be a case of focusing on the wrong issue. The real issue is not the presence or absence of the lock files. They are a result of the real issue, and until you address that problem, deleting, or trying to delete, lock files won't help.

At the risk of retracing old ground, let's review deployment.

Access applications need to be split into the interface (forms, reports, queries and code) and the data storage (tables only).

The interface, called a Front End, is an accdb. Each user has their own, exclusive, copy of that accdb. It is better to deploy each user's copy of the Front End, or FE, on each user's computer, although, as Gasman pointed out, a shared network drive location can work if it's set up adequately.

The data accdb, called a Back End, is deployed into a network folder. All copies of the FE accdbs link to the tables in that shared Back End, or BE. And that's where you "locking file" problem comes into the picture.

Because the BE is shared with one or more users simultaneously, there has to be a mechanism to keep track of all of those simultaneous users. The laccdb, or locking file, controls and tracks all of those users. Access creates it, modifies it, and deletes it. Not you nor your users. Only Access is supposed to manage the locking file. So finding that you need to manually delete it is a symptom of some other problem, and that's what you have to resolve.

One of the key features of this system is that all users must have sufficient permissions on the folder where the BE is located. This is under the control of IT. IT must allow each user to create new files (i.e. the locking file that is created when the first user starts Access and opens the BE). Each user must also have sufficient permissions to make changes to files (i.e. they have to be able to add records inside the accdb, update or delete them inside the accdb.) And each user must have sufficient permissions to delete files (i.e. the locking file).

Again, Access manages the locking file on behalf of users, but the users must also have sufficient rights for Access to make the required actions.

Hanging locking files can be a result of one or more users not having adequate permissions on the folder to perform all of those actions. If something goes terribly wrong, it is possible that a locking file can be left hanging, but under normal operations, you'll never need to intervene.

 

[gemma-the-husky]

I don't think it's a folder rights issue. If your process can't access the locking file you won't be able to use the database anyway.

I think the most likely thing is that users fail to close access, or even access crashes, or ties itself in knots, and the user has to close the front end with task manager. That will leave a phantom active session on the server, because crashing access won't allow the access process to exit gracefully and down date the locking file.

 

[Isaac]

Maybe the OP will chime in soon and enlighten us as to the desire to eliminate lock files

 

[Gasman]

Maybe the OP will chime in soon and enlighten us as to the desire to eliminate lock files

For when they hang around?
I have had that happen in my single user dbs, when Access crashed, or I had to kill it to due a code mistake.

 

[The_Doc_Man]

I don't think it's a folder rights issue. If your process can't access the locking file you won't be able to use the database anyway.

Technically not true. The first user who runs into that problem opens the file in Exclusive mode and everyone else gets locked out.

 

[gemma-the-husky]

Technically not true. The first user who runs into that problem opens the file in Exclusive mode and everyone else gets locked out.

I am surprised. Still maybe that's what's happened in this case, then.

 

[GPGeorge]

I am surprised. Still maybe that's what's happened in this case, then.

That's where I was headed as well. And why I invested in a pedantic review of permissions and locking files. It's rare, but not unheard of.

 

[RogerCooper]

If you have trouble deleting lock files, you can open them in Word and find out which users are in the file. Having them go back into the Access database and then exiting will sometimes clear locking problems. Otherwise, you need to delete the lock file at the server level.