Exclusive access in a shared environment

[Jaek]

Hello -
I'm having trouble with an application I'm distributing to multiple users on
a local network.

A certain percentage of the users are getting an error message saying that
they do not have exclusive access to the database and that 'any changes will
be lost'. The worst part is that this message is a 'looping popup', that is
when you click 'ok' the popup immediately reappears, ad infinitum.

-- These users have read/write access to the shared files in question.
-- Even though the looping popup effectively crashes the app, the ldb file
is being successfully created when these users open it.
-- When trying to trouble-shoot the problem, I have opened the database from
one of the problem terminals when no other users have had the db open, w/
same results.
-- Users sitting one cube over have no problem.

Any help is *greatly*appreciated.

 

[Douglas J. Steele]

It's not just read/write access to the shared files they need: they need
read/write access to the entire folder.

I've heard of issues where users have the ability to create an ldb file, but
not to use an ldb file created by another user. Unfortunately, I've never
actually seen this, so I haven't been able to determine what changes to the
permissions cause the issue.

 

[Jaek]

Thanks Doug, I mis-wrote. The users do in fact have read/write for the folder
- again, they are able to create an ldb even though the app is going nuts.

As far as the shared ldb, I don't think that was the issue as I tested with
problem terminals being the only user.

Thanks again.
J

 

[Paul Shapiro]

Users also need Delete privilege in the db folder, so the last user out can
delete the ldb file.

But from the sound of the initial issue, the users are all opening the same
shared Access file. This has been documented by Microsoft as the most common
cause of db corruption. Good practice for multiuser Access applications
requires a separate front-end database (containing the forms, queries,
reports and code) and backend database (containing just the tables). The
front-end db links to the tables in the backend. Each user should have their
own independent copy of the frontend database, ideally running from a local
disk drive and not over the network. But definitely not shared among
multiple simultaneous users.

I've found it easiest to store the current version of the frontend on a
network share. But users don't run that copy. They run a batch file that
copies that latest frontend to their local disk and then opens it from
there. This way each user has an independent, local frontend copy. They
automatically get the latest version anytime they start the application, so
distribution is not an issue.

Another possible cause would be users on different Access versions, or even
the same version with different service pack levels. Access seems most
stable when the user environments are uniform.

 

[david]

It might be an installation problem: some installation changes (eg Adobe
Acrobat)
make changes to the environment which require admin permission.

Try logging in to the problem workstation as Admin, run the program, then
see if the problem has gone away for the users.

You should also try opening the mdb without running the start code and
startup form.

(david)