DB opening as "Read-only" for some, not all

[KWarner]

Good morning,

Just today we have discovered a database we've been using for about a year
is opening as "read-only" for some people and not others!

We are all using Access 2000 and the file is saved on our server. The
database has not been modified, it is not marked read-only when I check the
properties, and I'm not allowed to convert it to Access 2000 - the option is
greyed out!

I'm not sure what happened. We modified a completely seperate database last
week, but the files are not connected in any way and even then we didn't do
anything with the security settings!

Any suggestions?

Thank you in advance for any help!

 

[Klatuu]

The first problem you have is multiple users sharing the same copy on a
server. This is not good for a number of reasons. Each user should have
their own copy on their own computer. The database should be split and the
back end (date) mdb should be on the server in a folder where all users have
read/write/delete permissions. It may be that permissions on the folder are
the cause of what you are experiencing.

 

[WD Rudman]

This is definitely a folder permissions issue. I ran into the same thing not
long ago.

As for Klatuu's suggestion: It depends on the database/application. If it
is in fact concurrent multi-user, then the suggestion is appropriate. I had
a db/app that needed to be accessed from different locations, by different
people, but was only ever used by one person at a time. To split the db and
write in permissions would have been overkill (certainly better standards of
programming, but overkill).

Also, when you place copies on various desktop PCs, you have to worry about
versioning/revisions.

 

[WD Rudman]

Forgot to post the solution to folder permissions -- give the people who need
it full control on the folder containing the mdb. If there are a lot, best
to create a network (Active Directory, I'm assuming) group.

 

[Klatuu]

I strongly disagree. Revisions and distribution are really not a problem and
actually easier with a split database.
If you have the data and all other objects in the same mdb, to make
modifications to the application, you have to wait until all users are out of
the application and copy each new and modified object into the production
version. This is time consuming and prone to errors.

The best practice is to maintain a production environment and a test
environment including an copy of the back end to allow you to do testing.
Once you are ready to deploy a new version of the front end, there are
several ways to do this. One is to put the new version in a shared location
and instruct your users to copy the new version into place. (Not a good
solution, but one you will see frequently) Another is to use a desktop
shortcut that does not open the application directly, but first copies the
"base" application from a shared location so the user always has the current
and compacted version. And the one I use mostly is a front end updater
system that involves a second mdb. The app compares it's internal version
number with a Current version field in a table in the backend and if it is
not current, opens the front end updater and closes itself. The updater then
renames the existing mdb, copies the new version into place, and starts it up.

When I read overkill in you post, what I am seeing is "I'm too lazy to do it
correctly"