Strange error

[Rob.Mills]

Hi all,

I have a folder on our network that contains several backends. They've been working fine for quite sometime. Just in the last couple of days people have been getting errors when they try to update a record that says record is currently locked could not update. Then the FE just freezes. I've also noticed that on the server everytime I look at the folder it contains a lock file for every backend in that folder whether someone's in it or not. The one's where no ones in it I am able to delete them. But if I go out of the file and back in the lock files are there again.

Has anyone had something remotely similar happened to them?

 

[The_Doc_Man]

Basically, there is a risk of this happening any time the network takes a hit that lasts longer than the keep-alive time that is used for each connection.

What happens is that the network times out. The session drops dead. Because the .LDB file was open, it shows a lock. But the REAL problem is that the .LDB file could not be properly deleted when the session died. (Windows isn't very good about that.)

This could also happen if the server crashed with the files still opened. Same result, different effect.

 

[Rob.Mills]

Is there anything I can do to prevent this?

 

[The_Doc_Man]

You can minimize the risks, but cannot fully prevent it.

1. Uninterruptible Power Supply on the server. (Wouldn't be a bad idea on the workstations, either.) Ditto all routers, bridges, hubs, anything else that handles network infrastructure.

2. In the server's reboot code, after you drop the server for any scheduled maintenance, have it delete ALL .LDB files before it enables the services that would allow file access.

3. Speaking of scheduled maintenance - you DO have a regular maintenance session on your calendar, once a month or at most two months, don't you?

4. Educate your users. Tell them to be aware of cases where they were in a database when something died. Have them REPORT the problem. That way, you know what to look for.

5. Assure that all users have proper access rights. (This is another reason why .LDB files hang.) A user who must open an Access database needs to be able to create a new .LDB file if they are the first person to open the database for the day. They also need to be able to delete the .LDB file if they are the last person to close the database for the day. Plus the ability to write or update the file. (Turn on the lights when you are first to enter; turn off the lights when you are last to leave.)

6. Speaking of scheduled maintenance - you REALLY DO have a regular maintenance session on your calendar, don't you. (No, that is NOT a typo or error of duplication.) During this session, you need to repair and compress your database.

7. Speaking of ONGOING maintenance - you should monitor the amount of free disk space on the drive holding the database. If you get to the point that you have less free space than the size of the database, your repair and compression operations will be in deep doo-doo. (Notice the high-tech language?)

8. Speaking of ONGOING maintenance - you DO have event logging turned on, don't you? You DO regularly examine the event logs for device errors, I hope? (Disk failures, even if transitory, will also have the described effect.)