Change data on Form and NOT on Table

  • Thread starter Thread starter Ricardo
  • Start date Start date
R

Ricardo

Hi

Is it possible to deny all users -- except the Admin -- of opening an
MS Access "database" in design mode (SHIFT+ENTER)?
I created the user USER belonging to the group USERS, but when I try
different combinations of permissions it doesn't do what I expect it
to.

What I want is to make sure that the user can only change the data on
a form and not on the table itself.

I won't mind if the user can open the tables, just don't want them to
change the data directly on the tables.

Help!!!!

Thanks,
Ricardo Ferreira
 
Ricardo said:
Hi

Is it possible to deny all users -- except the Admin -- of opening an
MS Access "database" in design mode (SHIFT+ENTER)?
I created the user USER belonging to the group USERS, but when I try
different combinations of permissions it doesn't do what I expect it
to.
Click to expand...

You need to download and study the security FAQ. You shouldn't apply
permissions to any user in the Users Group, nor to the Admin user. These
two entities are common to every workgroup file in the world.

There is a lot to setting up security. You can accomplish what you want,
provided you implement security properly.
The security FAQ is at
http://support.microsoft.com/?id=207793

Security Whitepaper
http://support.microsoft.com/?id=148555

Although the whitepaper is old, it contains information to help you
understand security.

I have also outlined the steps in detail at
www.jmwild.com/AccessSecurity.htm
What I want is to make sure that the user can only change the data on
a form and not on the table itself.
Click to expand...

You can deny users permission on the tables and have all data interaction
occur via forms based on RWOP (run with owner permissions) queries - details
in the FAQ.
 
Joan

Thanks, your website was really helpful.

I now have a better understanding of MS Access security.

I still have some questions though:

1) How to make sure that the members of a group can only change data
on the forms and not on the tables?

In User Group Permissions:
In order to tick the Add, Mod, Del boxes in Forms; I have to tick them
in Tables as well.

2) How to make sure that the shortcut with the /wrkgrp option is the
only way to open the database? Otherwise, one can always log in
through System.mdw and have Admin permissions.

3) This database is going to be deployed on a PC outside my network.
Will I have to rebuild the MDW file and set the permissions all over
again, or is it enough to copy the MDW file as well as the shortcut?

Thanks,
Ricardo Ferreira
 
Ricardo said:
I still have some questions though:

1) How to make sure that the members of a group can only change data
on the forms and not on the tables?
Click to expand...

Deny that group all permissions on the tables - they should have no
permissions on the tables at all. Your forms should be based on queries
instead.

You, as developer, will own the queries. In each of them, you can set the
'run permissions' property to 'Owner' rather than User. This sets the query
to what's called RWOP (run with owner permissions). You then give the group
permission to Read data, and update data for the query. Your form just
needs Open permission for the group.

When any member of the group opens the form, they will be able to read and
edit data (if they also need to add or delete records, you need to grant
this permission on the query).
In User Group Permissions:
In order to tick the Add, Mod, Del boxes in Forms; I have to tick them
in Tables as well.
Click to expand...

There is no Del permission on forms, and modify is modify the design, not
data. Your users don't need either of these permissions.
2) How to make sure that the shortcut with the /wrkgrp option is the
only way to open the database? Otherwise, one can always log in
through System.mdw and have Admin permissions.
Click to expand...

If you have implemented security properly, then they should not be able to
even open your secure mdb using the system.mdw workgroup. If they can, then
you missed a step in securing it. The Admin user and the Users group (the
same in all workgroup files), should have *no* permissions to anything, and
should not own any objects.
3) This database is going to be deployed on a PC outside my network.
Will I have to rebuild the MDW file and set the permissions all over
again, or is it enough to copy the MDW file as well as the shortcut?
Click to expand...

Just copy the mdw file. You may be able to copy the shortcut, but it is
likely that it will need to be modified to reflect the different paths on
the new network.
 
Thanks Joan.
I'll try that.

Ricardo

Joan Wild said:
Deny that group all permissions on the tables - they should have no
permissions on the tables at all. Your forms should be based on queries
instead.

You, as developer, will own the queries. In each of them, you can set the
'run permissions' property to 'Owner' rather than User. This sets the query
to what's called RWOP (run with owner permissions). You then give the group
permission to Read data, and update data for the query. Your form just
needs Open permission for the group.

When any member of the group opens the form, they will be able to read and
edit data (if they also need to add or delete records, you need to grant
this permission on the query).


There is no Del permission on forms, and modify is modify the design, not
data. Your users don't need either of these permissions.


If you have implemented security properly, then they should not be able to
even open your secure mdb using the system.mdw workgroup. If they can, then
you missed a step in securing it. The Admin user and the Users group (the
same in all workgroup files), should have *no* permissions to anything, and
should not own any objects.


Just copy the mdw file. You may be able to copy the shortcut, but it is
likely that it will need to be modified to reflect the different paths on
the new network.
Click to expand...
 
Back
Top