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

In some o/s, it is possible to give permissions for read and write but not
delete.

--
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.

The problem reoccurred yesterday. I was able to log on and can report
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

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

One of those OS's is named Windows.

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

Owen <google (AT) healthbase (DOT) com.au> wrote in
news:7295072f-b526-4416-947e-dfb084dc86d5 (AT) h37g2000pro (DOT) googlegroups.co
m:

It's not listed in the OPEN FILES list?

[]

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.

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

I spent 5 hours logged onto the client's 3 PCs last Friday and could
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

In that case it sounds like your code is failing to explicitly close what it
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-aff4-ce35ec8454f6 (AT) v20g2000yqb (DOT) googlegroups.com...

I spent 5 hours logged onto the client's 3 PCs last Friday and could
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

Hi Allen,

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

On Mon, 1 Nov 2010 22:25:39 -0700 (PDT), Owen
<google (AT) healthbase (DOT) com.au> wrote:

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.

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/

Problem is solved now, at last.

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.