‘Locked’ Database? (2003 SP2)

Topic

New Reply

I have a split database (back end on server) with multiple users. The ldb files for the back end and for the mdw file (both on the server) persist, even when no one is on the system (I’m looking at it in off hours). If I try to delete one of the ldb files I get a message “Error Deleting File or Folder – Cannot delete… It is being used by another person or program…” Because Access “thinks” another user is active, I can’t repair/compact or make design changes to the backend database. My guess is that some user terminated abnormally and left the ldb files in limbo. Is there a way to clear this up — my search for answers indicated that if the offending user can be identified and they log off and log back onto Windows, this may clear it up — if this is the case, is there a way to determine who the offender is?

Thanks.

Reply | Quote

Replies

Do you use Terminal services?

The reason I ask is that we do and quite often Access does not shut down properly for some reason, so i have to end the msaccess.exe process manually from the task manager on the terminal server.

Another option is to reboot the pc with the backend on, if that is possible remotely?

Reply | Quote

I use STS but none of the users do. I haven’t had a problem (so far) with Access not shutting down properly when using STS.

The backend is on a site-wide server “farm” — I doubt I could talk the administrators into rebooting it just for me… If that’s the only option, though, I may have to resort to that…

Reply | Quote

Okay, fair enough.

Thought I would highlight some problems I have experienced in the past when the lock file has been there.

Urm…. apart from mentioned before that is me at a lost end.

Reply | Quote

Luke –

Thanks for your ideas.

Reply | Quote

See How to determine who is logged on to a database by using Microsoft Jet UserRoster in Access 2000 (applies to later versions too).

Reply | Quote

Hans,

In my search, I did run across this article. At first I thought I couldn’t use the code since Access wouldn’t let me save/design anything (since it “thought” another user was using the database). However, I found I could enter the code from this article an run it — I just couldn’t save the module. I suppose this might be a handy utility to have in the database (ahead of time), for situations like this…

Okay, now that I know who Access thinks is using the database (besides me) — and I’ve confirmed that he actually isn’t, how do I clear him out? One thing I’ll try when he comes in tomorrow is have him log in to the database and exit (gracefully) and see if this “clears his name”. Any other ideas (particularly if this doesn’t work)?

Thanks,

Reply | Quote

The code from the article can be run from another database.

The network admin may be able to delete the .ldb file and “unlock” the database. If not, rebooting the server is probably the only way to solve this.

Reply | Quote

Hans,

The user-level security on this database doesn’t let me run the routine in the article you referenced. However, I found a variation of this routine (285822) that acts on the current database rather than an external one which circumvented the permissions hurdle. The routine did list the culprit user (plus me, of course).

I’ll see what the network administrator is willing or able to do for me.

Thanks for the help.

Reply | Quote