Access 2003 will not allow design access to db with no one logged on

[rbrake3]

I have a split Access 2003 database that has operated normally in this regard until now. It has been in use for 4 years and contains 44,000 records in the main table.

I ask all users to log off and then I open the backend and make changes as needed. Today, I needed to delete a corrupt record. I copied the database first. Using the copy as a test, I ran compact/repair and then was able to delete the record.

When I attempted the same process on the original of the database, I could not run compact/repair. An error message stated "You attempted to open a database that is already opened exclusively by user 'Admin'... The computer referenced is the one I am using. I checked and made sure I did not have Access open in any other instance. How do I convince Access that I am the only user logged onto the system? I checked and made sure no other users were logged on. I only have the one instance of the Access database open.

[Seth Schrock]

I get this occasionally when I try to create a backup of the database in Access 2010. All I have to do is close and reopen the database and it works. I normally get it when I have had it open all day without doing much to it.

[zmbd]

Yep, the other thing I've had to do is simply re-boot the computer as when I've check in the running tasks there will sometimes be a rogue Access program still running in the background.
There is a lock file that Access creates that sometimes doesn't clear too so let us know if this worked for you.

[ADezii]

As indicated by zmbd, Access creates a Locking File containg specific information whenever a DB is opened. This File should automatically be deleted when the DB is closed, but this is not always the case. Look for a *.ldb (Access 2003) File in the same Directory as the Database. If it does exist, and the Back End is closed and all Users are Logged Off, DELETE it.

[zmbd]

ADezii
I'm leary about just deleteding the lock file without rebooting the PC first, I've had data corruption.

On our network when this happened, I'd ask everyone to log out of their workstation while I watched the locking file and occationally it would close itself when the user logged out and yet didn't have the front-end open. Strange things I tell you ... strange things in that lake!

[SgtTurbo]

I too have experienced the problem referenced. I don't know the ramifications of deleting the 'Lock File' when it may still be needed; but my system won't allow me to delete the hanging 'Lock File' unless all users are logged out. I frequently find the problem is someone left their Windows Profile logged onto a Computer Workstation with the database opened, then switched users. So this makes it appear all instances of the database are closed (as all employees at the available computer workstations have reported they closed their instance of the database) when if fact there is still an instance of the database opened somewhere. We then have to go around to each computer and restart it till the 'Lock File' is automatically deleted (most often the case) or it is released and allowed to delete.

I once started (but never finished) designing a table/coding that logs opening the database then deletes that record when the user exits. I figured this would be of great use to know which User and on which Computer still has an instance of the database opened. We could then easily zero in on the source of this problem.

Logging the opening or closing of the database wasn't the problem I struggled with, but rather identifying the appropriate record to delete (using fields of: Date, Time, winUser, Computer, Open/Closed) particularly involving date changes as our operations are 24 hours a day, and the graveyard starts on one date then finishes on the next. I could be overthinking this and a solution may be much simpler.