Question LDB lock delete problem (1 Viewer)

[manny]

How can I delete a ldb lock file on the server without having to reboot the server?

I realise these ought to be deleted after the last user closes the shared access db but these ldb files were not being deleted.
I also realise that you ought to be able to see who the last user was by opening them with a text editor but I cannot open them as I get an access denied message. I have administrator rights. There is sufficient disk space.
All the users of the folder have create, read, write permissions.
No process on the server is keeping these lock ldb files open by checking in the Computer Administration / Open files area.
What is interesting is when looking at the properties of the file there is no Security or Summary tab. No ownership.
Hence this probably gives an explanation why I as Domain Administrator cannot delete them.
I remember in the past trying some Microsoft command line utility to force ownership of the file to Domain Administrator but this was unsuccessful.
Help!
In short all I want to know is there a utility out there that will let me delete these files without me having to reboot the server and any utility that will enable me to force permissions on a file?

 

[Guus2005]

Using the LDBViewer you can see who is locking the database without changing the file.
The LDBVIEW.EXE in the zip file was created by M$.
It gives you information on the computer locking the file.

Enjoy!

 

[manny]

Thanks for the quick reply Guus2005 and the LDBViewer utility.
Tried it and it says that there is nobody in the 3 x database files (-1 users in fact)
The databases were checked and repaired using the ODBC repair function so they are not corrupted so I think it is just the lock files that have the issue

 

[gemma-the-husky]

you can just delete the ldb file in windows

now if it will not delete, then there definitely is someone with the dbs open,

 

[manny]

You cannot delete the file with Windows Explorer on the server
"Error deleting file or folder. Cannot delete <filename>: Access is denied
Make sure the disk is not full or write-protected and that the file is not currently in use"
I have Domain Admin permission
The disk is not full >150Gb
Not write protected. Can see all permissions. Manually can create a new text file in folder.
Not in use. Guus2005 LDBVIEW.EXE utililty confirmed that. Also checking Computer Management / Shared Folders / Open Files confirms nothing is holding it open.

It is as I suspect the files have lost their ownership unless someone can tell me differently?

 

[manny]

Incidentally the MS file utility that I ran to try to get back ownership was SUBINACL but it failed

 

[gemma-the-husky]

"Error deleting file or folder. Cannot delete <filename>: Access is denied

Well somebody IS using the database then - thats why you cant delete the ldb file
maybe they turned off their machine without logging off - check active sessions etc

-------------
one other thing - can you confirm what is actually on the server?

you should have a split front end/back end, each user should have a distinct copy of the front end, and the shared data should be on the server

 

[manny]

I copied the database files to another subfolder and the users of the App are now accessing those databases so nobody will be using the old databases. If you can suggest another utility which will prove that there is somebody still using them then I would be happy to try it, but all the evidence so far is pointing that nobody is using them.

 

[manny]

I tried using the XCACLS.VBS <drive_letter>*.* program command but it doesn't even "see" the LDB files
I do a DOS directory listing and they are displayed
I tried using SUBINACL /FILE <driveletter>*.* /DISPLAY and it at least recognizes the LDB files but displays the error message "CreateFile Error : 5 Access is denied"

 

[manny]

gemma-the-husky I can confirm that each user has their own front end App and the data is on the server. There are only three people that will use that folder area for the databases. The folder is also restricted to them by ACL permissions. Looking at the open files I can see that 2 of the 3 users are now using the new folder area created and I can see the new databases open. The other user is not in today. There is no access to the old database location that has the problematic LDB files.

 

[gemma-the-husky]

i am not an expert on windows etc, but i am sure

either
a) you dont have delete permission on the folder, so you cant delete the ldb file (which I doubt) or
b) it is still locked by an existing terminal session

if b) then there must be an unclosed session - does your server login terminate connections after a certain time, or are they permanent - if the latter, then that would explain why rebooting the server then allows you to delete the file - because the active session is then killed off (only) by rebooting.

do you have a management console you can use to check active sessions/active file locks.

 

[Guus2005]

...
The other user is not in today.

I have encountered that users sometimes stay logged in, even when they're out. What i do is shut their computer down. To make sure they are logged out.

Worth trying?

 

[manny]

1. Definitely have delete permission for the folder
2. I do have a Windows Server 2003 management console and the 2 of the 3 users have sessions but are seen to be opening the new database files.

Of interest I have previous versions restore and I can see a copy made at 7am today. The LDB files are available for viewing by LDBVIEW.EXE and I can see the user admin and the 3rd person's workstation name who is not in today listed. The person's PC is powered off, I physically checked!
Off these previous version LDB's I can see a Security Tab when viewing the files properties unlike the problematic LDBs leading me to the corruption theory.

I realize that I can simply restore these backups or move the MDB's to a new folder - which I did - but I am still looking an easier deletion of these problematic LDBs for now and in the future. This situation has happened once ago in the past and ideally I am looking for a solution that isn't a sledgehammer approach.

 

[gemma-the-husky]

i'm pretty sure its not a corruption issue - its a windows session thing

when the third person's PC powered off, what happens to his session on the server - is that terminated on disconnection - if the terminate on disconnect is set to NEVER, then the session is probably still active

so if you kill that session in the management console, this will release the lock on the ldb file - then you can delete it.

 

[Guus2005]

I agree with gemma-the-husky that's it is a windows session thingy.
Sometimes the LDB file isn't deleted by Access when nobody is in the database but you can always delete it yourself, unless it is locked by someone.

Could you post the LDB file?

 

[manny]

Looking at the open session from the Computer Management console I can see 2 of the 3 users online but the 3rd person is not listed therefore their session has ended. If I then look at the Open Files view of the Computer Management console I can see 2 of the 3 users with open files pointing to the new directory location of the MDB files but none listed at all for the 3rd person. Looking at the previous version copy made at 7am I can see the last user to use was the 3rd person. The time of the 'corrupted' LDB files was around 18:30pm last night. I would certainly say the 3rd person was 'responsible' for this situation by probably crashing out of their PC for whatever reason.

 

[manny]

It won't let me copy the LDB file. The 'Access is denied' message re-appears.

 

[gemma-the-husky]

i would have thought if the windows session had terminated you would be able to delete the ldb file

this is 100% a windows thing

is there still an isolated MS-Access process running by any chance - that would keep the lock on the ldb file - try task manager

 

[Guus2005]

let the other users log out (shutdown their computers) and try again. There might be a residual trace to the LDB file left.

(grasping at straws)

 

[manny]

What Process Image Names would I be looking for in Task Manager on the server? Bear in mind the 2 users would probably be using that process legitimately with the copied version.