>This just hangs indefinirely (well 10-15 mins without result) when I try to 'preview'
>
>>Ok, I cleaned up my design a bit. WWhat fo you think of this?
>>http://www.filefactory.com/file/a0f795g/n/design_JPG
>>
>>
>>
>>>>
>>>>>>The purpose of the UserRights table is not clear to me. Do you intend that users should be given rights without being assigned to >>any roles?
>>>>
>>>>
>>>>Rights are assigned first to roles, Then a user is assigned one or more roles. Then any user right that is different than the role right is
>>>>stored in UserRights.
>>>>
>>>>So after login the rights for the user's roles are loaded, then the UserRights are loaded on top of them.
>>>
>>>Understood. But my gut feeling is that it will be too complicated for an end user (acting in an 'Admin' role) to get a clear picture of exactly *why* which rights are available to each user (the same problem exists on a lesser scale as soon as you allow users to be assigned to more than one role). Why not just create an additional role to handle the 'fine-tuning' and drop the UserRights table?
>>>
>>>>
>>>>>>Why are the password details in the UserRoles table rather than the Users table?
>>>>Because a user logs in as a specific role. His/her rights would be determined by the role they log into.
>>>

I cam't speak.

>>>Don't see this. Why allow a user to login in different ways to obtain different rights - why not simply require them to login as a different user?
>>>
>>>>
>>>>>>How do the RoleRights.AccessLevel and Rights.AllowDeny fit together?
>>>>
>>>>The table has been changed 'AccessLevel' should read 'AllowDeny'.
>>>
>>>OK. So is the AllowDeny field needed in the Rights table?
>>>
>>>Going back to my first comment above: I haven't really found a way, even with my simpler structure, of presenting a clear picture of exactly why a specific user is assigned a specific right. Any thoughts on this?
>>>Regards,
>>>Viv