Multi-User input and db protection

[JayhawkJim]

I have looked at the documentation for this issue and my eyballs started to
twitch after the first two sentences. The MS version is to hard for this
first-time access programmer to decipher. I have created a db, queries,
forms, charts (reports) and a swithcboard. Everything works fine. I want my
staff to be able to pull up a form or report from the switchboard that
accesses a query to display a graph of the requested db information but I do
NOT want them to be able to modify ANYTHING in design view. Also, once data
is entered via a form from the sitchboard, how can it be "locked in" so that
someone can't go back and 'fiddle' with the data or change information in the
db?

 

[Keith Wilby]

I have looked at the documentation for this issue and my eyballs started to
twitch after the first two sentences. The MS version is to hard for this
first-time access programmer to decipher. I have created a db, queries,
forms, charts (reports) and a swithcboard. Everything works fine. I want
my
staff to be able to pull up a form or report from the switchboard that
accesses a query to display a graph of the requested db information but I
do
NOT want them to be able to modify ANYTHING in design view. Also, once
data
is entered via a form from the sitchboard, how can it be "locked in" so
that
someone can't go back and 'fiddle' with the data or change information in
the
db?

This is a huge topic. First you need to apply user-level security, have a
look at my web site for a link to the FAQ. If your eye's were twitching
before then this will make them jump out on stalks.

Once you have your users, groups and permissions set up you need to disable
the bypass key (see the AccessVandal post for a link).

You will also need to split your application, make an mde file from your
front end file and deploy a discreet copy to each of your users. Sharing a
file is a major no-no, here's why:

http://www.granite.ab.ca/access/splitapp/why.htm

HTH - Keith.
www.keithwilby.co.uk

 

[ntc]

the first 2 replies are very good... if your users really would go into
design mode and change things intentionally - then you have to step up to
doing these recommendations; while at the same time knowing that
fundamentally Access is hack-able by the persistent devious. So know your
audience.

It sounds though that you really don't want to get into that level of
security management; so if your users are more casual and not inclined to
intentionally change things around - but you still need to minimize their
temptations/abilities; one can remove the Database Window at the StartUp
Option, remove/limit menu bar options; and create a separate front end with
forms locked so some users can not enter/change data.

This is easier than managing User Level Security - less secure of course -
but again one must know the audience...