Persistent ldb file can't be deleted

#1

I have a application where multiple front ends on separate PCs connect
to multiple back ends on a server. Each front end links to a single
back end at one time, and can specify which back end to link to. There
are no locks on the system so more than one front end can be linked to
the same back end.

Occasionally, a few of the back ends give the message that they can't
be opened because 'already opened exclusively by user .. bla bla.'
Initially I thought this was a corruption problem, but the files are
actually intact. If I close all the front ends, the ldb files in the
problem mdbs don't disappear. I can't delete them. If I reboot the
back end, then I can delete the ldb files, and the backends become
functional again.

Even when the ldb file can't be deleted, I can still open the mdb from
the front end PC in Access, either normally or exclusively. However
trying to open it from my front end application gives the 'can't open'
message.

Anyone know why I can't delete the ldb files when there is no-one in
the mdb file, and there has been no crash? And any suggestions at to
what might have caused this?

#2

If Access closes normally, the last front-end out should delete the LDB. If
this is not happening, it would suggest that either you have user whose
(network?) permissions do not allow them to delete the file, or that you
have a user/machine/network connection that is crashing out and so is not
cleaning up after itself.

Addressing that problem should solve the issue of the LDB.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Owen" <google (AT) healthbase (DOT) com.au> wrote

Quote:

I have a application where multiple front ends on separate PCs connect
to multiple back ends on a server. Each front end links to a single
back end at one time, and can specify which back end to link to. There
are no locks on the system so more than one front end can be linked to
the same back end.

Occasionally, a few of the back ends give the message that they can't
be opened because 'already opened exclusively by user .. bla bla.'
Initially I thought this was a corruption problem, but the files are
actually intact. If I close all the front ends, the ldb files in the
problem mdbs don't disappear. I can't delete them. If I reboot the
back end, then I can delete the ldb files, and the backends become
functional again.

Even when the ldb file can't be deleted, I can still open the mdb from
the front end PC in Access, either normally or exclusively. However
trying to open it from my front end application gives the 'can't open'
message.

Anyone know why I can't delete the ldb files when there is no-one in
the mdb file, and there has been no crash? And any suggestions at to
what might have caused this?

#3

"Allen Browne" <AllenBrowne (AT) SeeSig (DOT) invalid> wrote in
news:yoKdnSKpAqpuBCbRnZ2dnUVZ_o6dnZ2d (AT) westnet (DOT) com.au:

Quote:

If Access closes normally, the last front-end out should delete
the LDB. If this is not happening, it would suggest that either
you have user whose (network?) permissions do not allow them to
delete the file, or that you have a user/machine/network
connection that is crashing out and so is not cleaning up after
itself.

If it's the latter, you can find it by looking in the open files
list in the server's Computer Management tool.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#4

Thanks Allen,
The strange thing is that even when all users log out of the database,
on all PCs, the ldb file persists on the server and can't be deleted
until the server is restarted. Once restarted, it can be deleted, and
everything is back to normal. I'm getting the clients to try to
identify if it is a single PC that is causing the problem. Once the
problem occurs though, all PCs are locked out of that back end.
Owen

#5

On Oct 19, 9:50*am, "David-W-Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:

Quote:

"Allen Browne" <AllenBro... (AT) SeeSig (DOT) invalid> wrote innews:yoKdnSKpAqpuBCbRnZ2dnUVZ_o6dnZ2d (AT) westnet (DOT) com.au:

If Access closes normally, the last front-end out should delete
the LDB. If this is not happening, it would suggest that either
you have user whose (network?) permissions do not allow them to
delete the file, or that you have a user/machine/network
connection that is crashing out and so is not cleaning up after
itself.

If it's the latter, you can find it by looking in the open files
list in the server's Computer Management tool.

--
David W. Fenton * * * * * * * * *http://www.dfenton.com/
contact via website only * *http://www.dfenton.com/DFA/

Hi David,
Unfortunately in this case, the 'server' is just another PC on the
network, and is not running any server software.
The clients are not reporting any crashing either. I haven't quite
worked out the circumstances in which the problem occurs.
Owen

#6

If you can't use the tool David suggested, you could log people in and out
of the database yourself.

Use an AutoExec macro (or Load event of your startup form) to log them in.
Use the Unload event of a hidden unbound form that stays open in the
background to log them out.

This assumes you have created a table to log the user, who can be identified
like this:
http://allenbrowne.com/ser-53code.ht...etworkUserName

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Owen" <google (AT) healthbase (DOT) com.au> wrote

Quote:

Thanks Allen,
The strange thing is that even when all users log out of the database,
on all PCs, the ldb file persists on the server and can't be deleted
until the server is restarted. Once restarted, it can be deleted, and
everything is back to normal. I'm getting the clients to try to
identify if it is a single PC that is causing the problem. Once the
problem occurs though, all PCs are locked out of that back end.
Owen

#7

On Mon, 18 Oct 2010 15:59:04 -0700 (PDT), Owen
<google (AT) healthbase (DOT) com.au> wrote:

Quote:

Unfortunately in this case, the 'server' is just another PC on the
network, and is not running any server software.
The clients are not reporting any crashing either. I haven't quite
worked out the circumstances in which the problem occurs.

That option should be there are any Windows OS. Control Panel >>
Administrative Tools >> Computer Management >> System Tools >> Shared
Folders >> Open Files

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

#8

Owen <google (AT) healthbase (DOT) com.au> wrote in
news:101b88cb-a848-4668-9116-1a9cf8ffdbcd (AT) j4g2000prm (DOT) googlegroups.com
:

Quote:

On Oct 19, 9:50*am, "David-W-Fenton"
NoEm... (AT) SeeSignature (DOT) invalid> wrote:
"Allen Browne" <AllenBro... (AT) SeeSig (DOT) invalid> wrote
innews:yoKdnSKpAqpuBCbR
nZ2dnUVZ_o6dnZ2d (AT) westnet (DOT) com.au:

If Access closes normally, the last front-end out should delete
the LDB. If this is not happening, it would suggest that either
you have user whose (network?) permissions do not allow them to
delete the file, or that you have a user/machine/network
connection that is crashing out and so is not cleaning up after
itself.

If it's the latter, you can find it by looking in the open files
list in the server's Computer Management tool.

Unfortunately in this case, the 'server' is just another PC on the
network, and is not running any server software.

Er, yes it is. Every copy of NT-based Windows is running server
software. If it weren't, you couldn't access your MDB file from the
other computers.

The interface for doing this is exactly the same on a Windows
workstation as it is on a server.

Quote:

The clients are not reporting any crashing either. I haven't quite
worked out the circumstances in which the problem occurs.

I don't have any suggestions on that, but the point is, you can find
out who has what files open by going to CONTROL PANEL |
ADMINISTRATIVE TOOLS | COMPUTER MANAGEMENT and viewing OPEN FILES
under SHARED FOLDERS. That will tell you what users have a lock on
the LDB file.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#9

Owen <google (AT) healthbase (DOT) com.au> wrote in
news:d9914494-0c65-40ad-9351-55a0a68b5e6b (AT) p20g2000prf (DOT) googlegroups.co
m:

Quote:

The strange thing is that even when all users log out of the
database, on all PCs, the ldb file persists on the server and
can't be deleted until the server is restarted.

This suggests that they haven't really exited Access. You should
have them check TASK MANAGER to see if MSACCESS.EXE is really closed
or not.

If it is, then you may have networking problems.

Quote:

Once restarted, it can be deleted, and
everything is back to normal. I'm getting the clients to try to
identify if it is a single PC that is causing the problem. Once
the problem occurs though, all PCs are locked out of that back
end.

Again, you can identify the problem user/PC by using the Computer
Management console.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#10

Thanks for all the comments. Please excuse my ignorance re the
Computer Management. I've now found that and can see how to use it.
The client is currently problem-free but I'll check this first if/when
it happens again. Also I'll check if Access is really closed on the
front end, but I think it will be as the application closes gracefully
without crashing.

I'd be surprised if it was a read/write permissions issue since
clients need this to open the back end in the first place. But it may
well have something to do with how the network is set up. I have about
40 clients with a similar setup but no problems, so this is a very
unusual situation.

The application does log the Windows username and computername during
various tasks, including opening and closing so I may get some other
hint there as to which is the problem PC. I'll let you know if/when I
find the answer.

Thanks again,
Owen