.ldb file not auto deleting

[Guest]

I have two databases that are setup to run via a Scheduled task. Both files
are located on my local C: drive so I know no one else is accessing these
files. However, the Record-Locking Informaiton file isn't automatically
deleting like it normally does/should. I'm pretty sure that because these ldb
files are still open, it's not running the file when scheduled.

I tried opening the file and closing it, but that doesn't work.
Can I just delete this ldb file for each database? Thanks in advance.

Daniel Simoens

 

[Arvin Meyer [MVP]]

If an ldb file doesn't self-destruct it is usually because of an error
and/or a premature exit. Manually deleting (if you are able) the ldb won't
hurt anything, but it doesn't fix the cause either. Try stepping through
your closing code to find out what's causing the problem.

 

[Guest]

Thanks.
I've tried to delete and move the ldb file. neither work.
We had network drive problems last week and that is when this problem
started. The query wasn't able to access this network as someone turned off
the sharing so all files/folder were gone that this database was trying to
access.
I was able to copy the main database and paste it to a different folder. I
have it scheduled to kick off in a little while.
Code should be fine.

 

[Arvin Meyer [MVP]]

Thanks.
I've tried to delete and move the ldb file. neither work.

Usually you can delete it if you log in as administrator. Sometimes you must
reboot because the OS grabs the file thinking that someone is still
connected.

 

[Guest]

Thanks again.
Yeah I tried rebooting but the ldb files were still there. So I tried to
delete them after the reboot and it let me actually delete them. Lesson
learned!1 Reboot then delete.
Thanks Arvin!

 

[David W. Fenton]

Usually you can delete it if you log in as administrator.
Sometimes you must reboot because the OS grabs the file thinking
that someone is still connected.

If it's accessed through a share, you should be able to see who has
it open and have them close out, or force the file handle closed.
There are also utilities that will show you open files on non-shares
and allow you to force close the file handles for them.

 

[David W. Fenton]

Yeah I tried rebooting but the ldb files were still there. So I
tried to delete them after the reboot and it let me actually
delete them. Lesson learned!1 Reboot then delete.

You should have been able to find out who had the LDB open and have
them log off and log on again. Failing that, you can force close the
file handle. Either will release the file handles and allow you to
delete it. It's a pretty drastic solution to reboot a server just to
delete an open file!

 

[Arvin Meyer [MVP]]

If it's accessed through a share, you should be able to see who has
it open and have them close out, or force the file handle closed.
There are also utilities that will show you open files on non-shares
and allow you to force close the file handles for them.

Logging in as admin should allow them to do that, and that is what I first
suggested. There are a few times when nothing but rebooting will allow
closing an LDB file.

Two weeks ago, I had a problem trying to create a Terminal Server connection
to a server several states away. After about 20 minutes, I just had the
admin reboot the server and I was immediately able to connect. With Windows
machines, rebooting every few months seems to end all the annoying little
problems that crop up. On my own machines, the longest I've ever gone
without rebooting a server is about 15 months, but the machine wasn't
connected to the Internet no I didn't do any updates. Now, normally I reboot
after the monthly security updates.

 

[David W. Fenton]

Logging in as admin should allow them to do that, and that is what
I first suggested. There are a few times when nothing but
rebooting will allow closing an LDB file.

Rebooting the server (as opposed to rebooting the client
workstations)? I've never encountered that. That situation would
require a process on the server holding the file open, and that can
always be force closed with the utilities I mentioned.

Two weeks ago, I had a problem trying to create a Terminal Server
connection to a server several states away. After about 20
minutes, I just had the admin reboot the server and I was
immediately able to connect.

Likely a problem that doing a reset in TS manager would have fixed,
seems to me.

With Windows
machines, rebooting every few months seems to end all the annoying
little problems that crop up. On my own machines, the longest I've
ever gone without rebooting a server is about 15 months, but the
machine wasn't connected to the Internet no I didn't do any
updates. Now, normally I reboot after the monthly security
updates.

I disagree. Rebooting should be a last resort and should have very,
very, very seldom. A server that has to be rebooted every 15 months
is a server that needs to be rebuilt from scratch to get rid of
whatever crap is making it unreliable.

 

[Guest]

The reboot I was referring to was my workstation. the database was on my
local C drive.

 

[Arvin Meyer [MVP]]

Likely a problem that doing a reset in TS manager would have fixed,
seems to me.

That was one of the first things the admin tried. Several times, in fact.

I disagree. Rebooting should be a last resort and should have very,
very, very seldom. A server that has to be rebooted every 15 months
is a server that needs to be rebuilt from scratch to get rid of
whatever crap is making it unreliable.

Monthly server maintenance at every enterprise I've ever worked at includes,
adding all patches required, defragging the drive if required and rebooting.
The only servers that escape that routine are ones which are required to be
up 24/7. I have been an admin at only a few domains in the last 5 years, so
the routine is usually carried on by full-time domain admins. It was not
uncommon to rebuild a server in NT4 days, but to my knowledge, it is very
uncommon now. The only ones that I know of, were flattened due to a virus
that was easier to guarantee had been successfully destroyed by rebuilding
the server.

At any rate, based on the poster's response, rebooting was done on a client
machine and solved his problem.