Permissions

  • Thread starter Thread starter Wembly
  • Start date Start date
W

Wembly

Hi,

I have set the permissions for all object types using
the "group" rather than the individual "users". In User
And Group Accounts, all users are either grouped
into "users" or "admins".

There is one particular table that does not appear to
store the permissions that I have set. The first time I
log in as another user, the table is accessible by the
user. This table is accessed via a query which is fired by
a button click event.

However, if I log in the second time, either as the same
user or another user, this table will have lost all it's
previously set permissions. This means I have to always
log back in with admin rights and set the permissions
again.

If I have to do this al the time, I will go nuts. I do not
understand why the permissions are getting reset for this
table only and not the other tables which I also have
permissions for.

Desparate help is needed.

Thx
Wembly
 
There is no way that a table will suddenly "lose its permissions". Your
conclusion that this is hapenning, must be incorrect. Set out the precise
sequence of steps & events, which causes you to make that conclusion. The
information you gave below, is good as an overview, but you need a lot more
detail. Set out the series of steps, as if you were writing an instriuction
to someone else, telling them exactly how to reproduce the problem.

HTH,
TC
 
Hi TC,

Okay here it goes:

Step1.
Log in as admin. This is required because the mdw has
already been joined, and I need to check the status quo of
the assigned permissions. Admin has been assigned to two
group accounts ie. users and admins.

Step2.
Go to security and check that the permissions for all
objects including the culprit table tbl_xxx has been setup
properly under the users group (admins group is okay, no
problems here). There are about 20 different users and two
admins. The 20 users do not have any individual
permissions assigned to them but are rather assigned to
the users group. Same with the admins' accounts, which are
assigned to the users and admins groups.

I confirm that all the permission are correct.

Step3.
Close my application (including Accesss). Then load it
again logging in as a user (as opposed to my own admin
account). Then click a button which fires a macro which
opens a make-table-query. This query looks at a linked
table and copies it to another table tbl_xxx (the culprit
table).

Step4.
This works fine. Allows access to the user which I am
logged in as.

Step5.
Close this database (including Access). Then log in again
as either the same user as in Step3, or as another user
from one of the other 19 users. I then repeat Step3 and I
get an error msg to this effect: "...do not have access to
tbl_xxx, please get an admin to provide the correct
permissions..."

Step6.
I would then close it all down and then reload it and
login as admin again and check from Step1. Surely enough
tbl_xxx's permissions have been removed (all ticks that I
had set are now gone).

I hope this explaination is a bit better.

Wembly
 
Hi Wembly

My brain is mush at the moment! I'll print that out, review it tonight &
reply tomorrow.

Cheers,
TC
 
Hi Wembly,

Wembly said:
Hi TC,

Okay here it goes:

Step1.
Log in as admin. This is required because the mdw has
already been joined, and I need to check the status quo of
the assigned permissions. Admin has been assigned to two
group accounts ie. users and admins.
Click to expand...

In a properly secured mdb, the Admin user should not have permissions to
(nor own) anything. You should have created another user to be a member of
the Admins group, and removed Admin from the Users Group.
Step2.
Go to security and check that the permissions for all
objects including the culprit table tbl_xxx has been setup
properly under the users group (admins group is okay, no
problems here). There are about 20 different users and two
admins. The 20 users do not have any individual
permissions assigned to them but are rather assigned to
the users group. Same with the admins' accounts, which are
assigned to the users and admins groups.
Click to expand...

The Users Group should have no permissions at all. Any permissions you
assign to the Users Group will be permissions that any one using any
workgroup file (including the default system.mdw) will have. Is that really
what you want?
I confirm that all the permission are correct.

Step3.
Close my application (including Accesss). Then load it
again logging in as a user (as opposed to my own admin
account). Then click a button which fires a macro which
opens a make-table-query. This query looks at a linked
table and copies it to another table tbl_xxx (the culprit
table).
Click to expand...

A make table query creates a *new* table, deleting the existing one in the
process.
Step4.
This works fine. Allows access to the user which I am
logged in as.

Step5.
Close this database (including Access). Then log in again
as either the same user as in Step3, or as another user
from one of the other 19 users. I then repeat Step3 and I
get an error msg to this effect: "...do not have access to
tbl_xxx, please get an admin to provide the correct
permissions..."
Click to expand...

Correct. Remember that tbl_xxx is now a new table - it doesn't have the
same permissions that the original one did.
Step6.
I would then close it all down and then reload it and
login as admin again and check from Step1. Surely enough
tbl_xxx's permissions have been removed (all ticks that I
had set are now gone).
Click to expand...

You can achieve what you want by
1. Granting the necessary permissions to the <New tables/query> item (not
recommended)
or
2. Instead of using a make table query, run a delete query to clear the
table, and follow that with an append query.

Having said that, I don't think you have secured the database correctly to
begin with. Download and study the FAQ from
http://support.microsoft.com/?kbid=207793

It's not likely that you want to assign permissions to the Users Group, nor
the Admin User.
 
Hi Wembly

So you:
1. Create a new table;
2. Change permissions on that table;
3. Run a process (the make-table query) which >deletes<, then >re-creates<,
that table, then
4. Expect the permissions on the new table, to be those that you set in step
2.

But that's like saying: "I bought a car. I added some red seat covers. Then
I sold it & bought another one. Why doesn't the new one have red seat
covers?" Answer: it's a different car!

To retain the existing permissions, you'd have to delete the existing
records & re-add them with an Append query. I saw this last night when I
read the printout of your post, but naughty Joan has beaten me to it!
Doubtless you should consider her other points as well.

Cheers,
TC
 
Back
Top