How revoke different from deny?

Regarding the permission check marks, the manual says:
'The green check mark grants the permission, the red X denies the
permission, and the blank box revokes a previously set permission.'
I'm not clear how a blank box is different from a box which has a red X
mark? Do both all mean deny?
BingNever mind. I've figured out how revoke is different from deny.
Bing
"bing" wrote:

> Regarding the permission check marks, the manual says:
> 'The green check mark grants the permission, the red X denies the
> permission, and the blank box revokes a previously set permission.'
> I'm not clear how a blank box is different from a box which has a red X
> mark? Do both all mean deny?
> Bing|||The grants, revokes and deny's work with our role based permissions.
Follow this example and see if it helps you to understand:
I have a database with a table in it called Table1.
I have a user named Frog who would like to work with Table1.
Frog belongs to the Public role. (Everyone is always a member of public).
Frog also belongs to another role called Marketing
Frog also belongs to another role called Accounting.
SELECT permissions on Table1 have been set as follows:
Public <-- Grant
Marketing <-- Revoke
Accounting<-- Revoke
Frog <-- None set (which is the same as Revoke).
You must combine all the permissions for Frog to determine whether or not he
is allowed to SELECT from Table1. Looking at all of the permissions, here
are the rules:
1. He must be Granted somewhere in his list of permissions.
2. He must NOT be denied anywhere in his list of permissions. (Once
Denied, ALWAYS denied).
From our example above, Frog does have SELECT permissions on Table1 becausse
he was granted them by his membership in Public.
If we modify that permission scheme as follows:
Public <-- Grant
Marketing <-- Deny
Accounting<-- Grant
Frog <-- Grant
We then follow our rules:
1. He has been Granted somewhere in his list of permissions.
2. He was denied somewhere in his list of permissions.
Therefore, He DOES NOT have SELECT permissions.
If we revoke all permission on the table as follows:
Public <-- Revoke
Marketing <-- Revoke
Accounting<-- Revoke
Frog <-- Revoke
Check our rules:
1. No grant anywhere in the hierarchy, therefore, no SELECT permissions.
2. Not denied anywhere, but see rule 1.
HTH
Rick Sawtell
MCT, MCSD, MCDBA