Persistent ldb file can't be deleted
Owen
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?
Allen Browne
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" <goo...@healthbase.com.au> wrote in message
news:d068c7c1-80c1-4c76...@29g2000prb.googlegroups.com...
David-W-Fenton
news:yoKdnSKpAqpuBCbR...@westnet.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/
Owen
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
Owen
wrote:
> "Allen Browne" <AllenBro...@SeeSig.invalid> wrote innews:yoKdnSKpAqpuBCbR...@westnet.com.au:
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
Allen Browne
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.html#GetNetworkUserName
--
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" <goo...@healthbase.com.au> wrote in message
news:d9914494-0c65-40ad...@p20g2000prf.googlegroups.com...
Tony Toews
<goo...@healthbase.com.au> wrote:
>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/
David-W-Fenton
news:101b88cb-a848-4668...@j4g2000prm.googlegroups.com
:
> On Oct 19, 9:50�am, "David-W-Fenton"
> <NoEm...@SeeSignature.invalid> wrote:
>> "Allen Browne" <AllenBro...@SeeSig.invalid> wrote
>> innews:yoKdnSKpAqpuBCbR
>>
>> > 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.
> 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
news:d9914494-0c65-40ad...@p20g2000prf.googlegroups.co
m:
> 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.
> 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.
Owen
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
Allen Browne
>
> 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.
In some o/s, it is possible to give permissions for read and write but not
delete.
Owen
the following...
There are 3 PCs, one of which acts as the server/backend.
There was no crashing of Access. The task manager never showed Access
open when my app had closed.
Users can switch between backends from within my app - this uses code
(Set dbToOpen = DBEngine.OpenDatabase(strFolder & strFileName)) to
open the back end and link the tables. When opening some back ends
(which are not already open) this results in err 3045 - Could not use
<filename>; file already in use. After that the matching ldb file
persists until the backend PC is rebooted.
I've checked the Computer Management and can see links to the front
ends. However, when Access is truly closed on all 3 PCs, there are no
links to anything. Even so, the ldb files can't be deleted - message
given is 'Cannot delete <filename> : Access is denied'.
After opening and closing the backends multiple times, 9 of 20
backends displayed the persistent ldb problem. This might suggest a
problem with the specific backend files, however, some of the other
backends displayed this problem in days previous.
When opening the backends directly in Access, those with a persistent
ldb open 'read-only', the others are editable.
The problem is intermittent - the client reports that it is more
likely in the afternoon than morning!
Could a network problem cause this? How?
The problem can be fixed by rebooting the server PC and deleting the
ldb files. The reboot is necessary for this. Then all 3 PCs work
happily for a while until one reports a locked back end again, usually
some hours later.
Thanks again.
Owen
David-W-Fenton
> "Owen" <goo...@healthbase.com.au> wrote in message
> news:fbcc6f3b-4653-49c0...@w38g2000pri.googlegroups.
> com...
>>
>> 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.
>
> In some o/s, it is possible to give permissions for read and write
> but not delete.
One of those OS's is named Windows.
David-W-Fenton
news:7295072f-b526-4416...@h37g2000pro.googlegroups.co
m:
> I've checked the Computer Management and can see links to the
> front ends. However, when Access is truly closed on all 3 PCs,
> there are no links to anything. Even so, the ldb files can't be
> deleted - message given is 'Cannot delete <filename> : Access is
> denied'.
It's not listed in the OPEN FILES list?
[]
> The problem can be fixed by rebooting the server PC and deleting
> the ldb files. The reboot is necessary for this. Then all 3 PCs
> work happily for a while until one reports a locked back end
> again, usually some hours later.
My guess is that rebooting the client PCs would also work, because
it's one of the client PCs that's holding the lock on the LDB file.
Owen
not resolve the problem. However it did appear limited to one PC.
Intermittently, when this PC opened a back end in code, it would
return the 3045 error. This happened when no-one else had the back end
open. Subsequently, no other PC could open that back end using my app.
However, opening MS Access separately allowed opening the back end via
the menu, although it opened read-only. Rebooting the front ends made
no difference. Closing all instances of Access made no difference. The
ldb files persisted on the server PC until a reboot allowed them to be
deleted. I've searched the newsgroups for difficult to delete files,
but no explanations were helpful. I ran Office and Windows updates on
the problem PC, and ran an Office repair process. I have advised the
client that I can do no more, and that if the problem persists, a
complete Office, and possible Windows reinstall is recommended.
Thanks for all the suggestions. This has been the strangest problem
I've even seen. I hope it just goes away!
Owen
Allen Browne
opened.
If you used:
Set db = OpenDatabase(...
then make sure you explicitly:
db.Close
Set db = Nothing
after closing and dereferencing everything that relies on db, and ensure
this happens in your exit handler (i.e. even if the code drops to error
handler, it should do the above.)
If that doesn't solve it, and it the same routines work fine in other
computers, you are down to looking for what's different on that machine. For
example, it may have an older version of msjet40.dll
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" wrote in message
news:5efe9a31-7ba4-45de...@v20g2000yqb.googlegroups.com...
Owen
Thanks, I always close db objects and set to nothing, and always after
errors. This is something different. I'll look into the Jet version
next. I suspect it could also be a network permissions issue.
Owen
Tony Toews
<goo...@healthbase.com.au> wrote:
>I suspect it could also be a network permissions issue.
If only one user at a time can access a given backend then yes that's
a possibility. One problem though is that it's not necessarily the
user who is getting the error message that doesn't have enough
permissions. Instead it's the person who is already in the database
"locking things out" for the other users.
If there's an LDB file present that can help figuring out who that
user is. If not you'll need to ask the IT admins who has a lock on
that file. And hope they take a look quickly enough while the other
user is still in there.
Owen
The data was on an XP machine, with links to another XP machine and a
Windows 7. I moved the data to the Win 7 PC and in doing so, had to
adjust the permissons on Win 7 to allow the 2 XP machines to edit the
data. This has fixed the problem, so I guess it was something to do
with the Win 7 permissions on the network. I'm not sure if it would be
OK now with the data back on the original XP machine, but I'm not
going to try, now that it's working well.
Thanks for all the advice.