How to delete ldb files when no one is in the database.

[RW]

The database in on a network server. Users access the database through Citrix.

The network server has been bounced.
The citrix servers are bounced nightly.
The network admin can not see the .mdb or .ldb files from the network
management software indicating no one is logged into the database. However,
the .ldb files are on the network server. The network admin can not manually
delete the .ldb files either (when using explore to view the files). It gives
a message that the database is locked.

If you open the .ldb file in notepad, it displays the Citrix server name as
the user.

I've downloaded LDBviewer and it shows Logged On "No" and Suspect "Yes".

How do I delete the .ldb files or change the database so it isn't "Suspect"?
This is preventing me from performing maintenance on the database. It should
be noted that I can go in and change forms, queries, Table design etc. - I
just can't Compact and Repair.

Thanks

 

[Albert D. Kallal]

someone still has the file opened, else you would be able to delete that
file.

Use the system admin tools on the server side to see who has what files
open.

Another simply way to test this is simply simply re-boot the comuter and
then you be albe to delete the file...

In other words....if you can't delete the file, then somone still has it
opened.

So, simply re-boot the computer...and you be albe to delete the file...

On the other hand, doing the above is VERY LIKEY to damage and currupt the
mdb data file, so, you best find out who has it open, but assuming you have
a good backup of the data file...try the re-boot idea.....

 

[RW]

Thanks for trying to assist.

As previously stated, the Network Admin tools do not show the .mdb or .ldb
files indicating no one has it open/locked. But using Explore on the server
does show the files. They can not be deleted from the server Explore either.

Rebooting the computers (and restarting Citrix) does not get rid of the .ldb
files on the server.

Microsoft LDB Viewer shows one or more Citrix servers to have the database
in a "Suspect" state.

 

[RW]

That's what we thought too. However, the ldb file still can't be deleted and
we made sure to try before anyone could get back into the database.

 

[Albert D. Kallal]

Thanks for trying to assist.

As previously stated, the Network Admin tools do not show the .mdb or .ldb
files indicating no one has it open/locked. But using Explore on the
server
does show the files. They can not be deleted from the server Explore
either.

Rebooting the computers (and restarting Citrix) does not get rid of the
.ldb
files on the server.

Microsoft LDB Viewer shows one or more Citrix servers to have the database
in a "Suspect" state.

 

[Albert D. Kallal]

Rebooting the computers (and restarting Citrix) does not get rid of the
.ldb
files on the server.

I never said rebooting will get rid of the file, but I did say it WILL allow
you to delete the file AFTER you re-boot.

Try rebooting, and see if you can then delete the ldb file when signed on as
an admin on that server....

 

[RW]

Sorry I wasn't clear but the ldb file can't be deleted either after
rebooting. Is there a way that I can change the "suspect" flag that I see in
LDB Viewer ("yes" in the Suspect column)?

 

[Albert D. Kallal]

Sorry I wasn't clear but the ldb file can't be deleted either after
rebooting. Is there a way that I can change the "suspect" flag that I see
in
LDB Viewer ("yes" in the Suspect column)?

Why would you care what is inside of a word file?
Why would you care what is inside of a power point file?
Why would you care what is inside of a Excel file?

And, why would you care what is inside of some file with some arbitrary file
extension of ..ldb?

A horse is a horse is horse

A file is a file is a file.

You are deleting a windows file. Why would you care if this is text file, a
word file, or some other arbitrary file that you no longer need?

You are simply going to delete a windows file here. At this point in time
this issue has absolute NO relationship to ms-access in ANY way shape or
form ****unless**** that file is still opened .

So, what you need to do is find someone in the IT industry that has the
ability and training that allows them to delete a plane Jane simple windows
file.

Either 2 cases exist:

1) you IT department has never deleted a windows file and does not
understand the idea and concept of a windows file.

2) You are incorrect in that no other process or application has that file
open.

There really not much else to go on here......

 

[RW]

1. You are correct that a file is a file.
2. Our IT dept does know how to delete files.

OK, you may have a point with "You are incorrect in that no other process or
application has than file open." However,

If the Network server has been bounced (this past weekend) AND all Citrix
servers have been bounced (every night), what process could possibly have the
file open. We tried to delete the file on Sat. before anyone got into any of
the databases without success. This is why it is so confusing.

BTW, This is actually happening on all of our databases. In fact, I can be
the only one to open a database and then close it. Sometimes the ldb file
disappears. I can reopen the databsae later and the ldb file won't go away
when I close the db. Also, if the ldb file exists (and no one is actually in
the db), I can open the db and proceed to compact it. Later I can try it
again and it says the db is locked by 'Admin' and provides the Citrix server
name that I am on.

None of this really makes since.

 

[Douglas J. Steele]

Is it possible that something in your application is instantiating another
instance of Access through Automation?

Is there any way to check the processes running on the server to see whether
MSACCESS.EXE is running?

 

[Ron]

Is it possible that something in your application is instantiating another
instance of Access through Automation?

Is there any way to check the processes running on the server to see whether
MSACCESS.EXE is running?

--
Doug Steele, Microsoft Access MVPhttp://I.Am/DougSteele
(no e-mails, please!)











- Show quoted text -

I had strange things like this happening on my system every so often.
When I asked about it here, someone asked me if I'd loaded and
installed all the updates to both Windows and Office/Access. I had
installed all the updates for windows, but I hadn't for Office. After
installing all the updates for my version of Office/Access on all
users, I no longer have an issue with leaving behind locked .ldb
files.

Dunno if it'll help, but may be worth a try?

Hang in,
ron

 

[David W. Fenton]

However, the ldb file still can't be deleted and
we made sure to try before anyone could get back into the
database.

Have you used something like Process Explorer to find out which
process has the file open? Likely the reason the server admin tools
don't show it as being open is that it's being accessed through the
local file system, whereas the admin tools only show you files
opened in network shares. Thus, there's a local process that has the
database open and has a lock on the LDB file. Process Explorer is
here:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

 

[David W. Fenton]

Either 2 cases exist:

1) you IT department has never deleted a windows file and does not
understand the idea and concept of a windows file.

2) You are incorrect in that no other process or application has
that file open.

There really not much else to go on here......

Albert, I think you're jumping the gun here. It seems likely that
something running on the server is opening the database each time
the server is rebooted. The reason it doesn't show up in the server
admin tools as an open file is because it's being opened locally,
and not via a network share. Thus, you need to find out what process
has the database file open (and is causing the LDB file to be
created). As I suggested in another reply, Process Explorer makes
this easy (you use the FILE HANDLE search and put in the full name
of the MDB file, or the LDB file), and you can either kill the
process that's opening the MDB or force close the file handle. Or,
if you know how to stop the process that has the file open without
force killing it, that would be better still.

For instance, with Jet replication, when the Jet synchronizer is
running, all managed databases are open, with an LDB file. If you
stop the Jet synchronizer, the managed databases are closed and the
LDB files will disappear.

I doubt the Jet synchronizer is involved here, but the point is that
certain processes outside your app could have a reason for opening
your MDB files and would thus be keeping the LDB open. The key is to
identify which process has the file open and then determining the
most orderly way to end that process.

 

[David W. Fenton]

If the Network server has been bounced (this past weekend) AND all
Citrix servers have been bounced (every night), what process could
possibly have the file open. We tried to delete the file on Sat.
before anyone got into any of the databases without success. This
is why it is so confusing.

BTW, This is actually happening on all of our databases. In fact,
I can be the only one to open a database and then close it.
Sometimes the ldb file disappears. I can reopen the databsae later
and the ldb file won't go away when I close the db. Also, if the
ldb file exists (and no one is actually in the db), I can open the
db and proceed to compact it. Later I can try it again and it says
the db is locked by 'Admin' and provides the Citrix server name
that I am on.

Something is running at boot that opens your MDBs. Use Process
Explorer to indentify what running process has the file open:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Then you can figure out whether that process is necessary and if it
can be shut down in an orderly manner, or if you have to force it to
shut down.

Your IT folks ought to know all of this. If they don't, then they
really aren't very competent, in my opinion.

 

[RW]

We aren't doing any automation.

We have set up a time tomorrow to go bounce the server, disconnect it from
the network and try to delete the files locally. Then we will reconnect it to
the network.

Thanks

 

[HWhite]

a couple of things I would try...

try deleting the file through command prompt

try logging in locally on the server and see if you can delete the file

I assume you've checked task manager after every reboot to make sure
msaccess.exe isn't loading. If you haven't, see if it is there. If so,
something obviously is loading at server startup.

Rename msaccess.exe to msaccess.xyz and reboot server. Try deleting the
file if it is there. Rename access back to .exe when finished. If the .ldb
isn't there, you know the server itself is loading access at startup. Check
event logs to see a failed application launch or services for failed startup.

If you are hands-on with the server and you suspect the file might be opened
over the network. Disable the network card, rename msaccess.exe to
msaccess.xyz and reboot. If you do this MAKE SURE you know the local login
password. Test it beforehand. After logging in, there should be no chance
in hell that the .ldb is still there. But, with your luck it probably will
be.

These are things I would try to troubleshoot this issue. No warrantees or
guarantees... do at your own risk... blah blah blah... and make sure you
re-enable the network card.

Good Luck.

 

[HWhite]

"Disable the network card"

oh yah, I guess you could just unplug the cable... DOH

 

[David W. Fenton]

We have set up a time tomorrow to go bounce the server, disconnect
it from the network and try to delete the files locally. Then we
will reconnect it to the network.

In the meantime, have you tried my suggestion, of using Process
Explorer to find out what process is holding the file open? If not,
I'd strongly advise it, as it could potentially allow you to avoid
all the down time.

 

[RW]

Well, Access wasn't running on the server either. We had to disconnect the
server from the network and delete the files. Now as we are working this
morning, the ldb files aren't closing when we close a database. So we are
back to square 1.

 

[David W. Fenton]

Well, Access wasn't running on the server either. We had to
disconnect the server from the network and delete the files. Now
as we are working this morning, the ldb files aren't closing when
we close a database. So we are back to square 1.

Are you ignoring my posts? There's a definitive way to find out what
process has each file open. Is there some reason you don't want to
find that out?