Spurious write-protected message

[Laurel]

I have a database that is linked to a backend database. The "front end"
application is installed on a number of computers at a school. The back end
is installed on a server. Typically, when the front end is copied onto a
computer, we get the message "The database DynamicMinds is write protected
you will not be able to.... <I forget>." To get rid of this, we right-mouse
on the application (front end) database, choose properties, and uncheck the
"write protected" checkbox. But we have one computer where the message is
displayed but the "write protected" checkbox is not checked either on the
front end or back end database. AND it is possible to update information on
the backend database. I'm not at the site, so I don't know if it's possible
to make modifications to the front-end application.

Does anyone know what might cause this message if
right-mouse/properties/write-protected is unchecked on both the front and
back end databases?

 

[CCC]

I have a database that is linked to a backend database. The "front end"
application is installed on a number of computers at a school. The back end
is installed on a server. Typically, when the front end is copied onto a
computer, we get the message "The database DynamicMinds is write protected
you will not be able to.... <I forget>." To get rid of this, we right-mouse
on the application (front end) database, choose properties, and uncheck the
"write protected" checkbox. But we have one computer where the message is
displayed but the "write protected" checkbox is not checked either on the
front end or back end database. AND it is possible to update information on
the backend database. I'm not at the site, so I don't know if it's possible
to make modifications to the front-end application.

Does anyone know what might cause this message if
right-mouse/properties/write-protected is unchecked on both the front and
back end databases?

 

[Dirk Goldgar]

In

Does anyone know what might cause this message if
right-mouse/properties/write-protected is unchecked on both the front
and back end databases?

The first thing that comes to mind is that the user doesn't have write
permission on one folder or the other.

 

[Laurel]

We looked at the folders, and none of them have the write-protected checkbox
checked.

 

[Laurel]

CCC, if you meant to submit an answer, I don't see it here.

 

[Dirk Goldgar]

In

We looked at the folders, and none of them have the write-protected
checkbox checked.

That's not quite the same as not having write permissions, and I'm not
sure whether you would see a check in the read-only box or not. Are
these folders on the network? I'd suggest making sure that the user in
question can create, modify, and delete a file -- use a simple text file
to test with -- in both of the folders in question, the one where the
front-end resides and the one where the back-end resides.

 

[Ro477]

I can't answer the problem, but we have a similar arrangement in our office
with a number of databases and I found that in the end it was easier to have
the front end on the server and run it from there, rather than have it on
the local workstation. That way if there are any changes to be made to the
front end you only have to do it once and not at each workstation ! From a
time and processing speed situation having it on the server (we have SBS2K3)
on the workstation (WinXP) made no discernable difference... Ro

 

[Dirk Goldgar]

In

I can't answer the problem, but we have a similar arrangement in our
office with a number of databases and I found that in the end it was
easier to have the front end on the server and run it from there,
rather than have it on the local workstation. That way if there are
any changes to be made to the front end you only have to do it once
and not at each workstation ! From a time and processing speed
situation having it on the server (we have SBS2K3) on the workstation
(WinXP) made no discernable difference... Ro

Bear in mind that this approach increases the chances of a corruption of
the front-end, as Access is constantly updating the front-end as you
work with it. Also, if you are having multiple users sharing the same
copy of the front-end, you're more likely to experience lockouts as two
users modify the same object.

The most common way to avoid those problems is to let each user have
their own local copy of the front-end, but
use a utility to automatically update the front-end from a network
"master copy" whenever the master copy changes. Tony Toews' Auto FE
Updater (http://www.granite.ab.ca/access/autofe.htm) is one example of
such a utility.