Hi All,

> Altering the concept of SQL Privileges to make it work differently to the
> standard is a VERY UNLIKELY objective,

even if there were nothing else to do. ;-) Like Doug, I think you really
*still* don't understand how roles are intended to work.


Personally I'm pretty confortable with the way roles work. I use to have a
role for each different client application that uses the database deppending
on their supposed job and some other especific roles for 'administration'
(for those logging with some tool like FlameRobin).

But... no user ever has more than *one* role granted to it, because I find
of
no use at all. Clearly a client application won't be choosing roles (even
users aren't happy doing so). And more...

Lets say you have a database for inventory (stock) management and PoS. and 2
client apps, 1 for managing inventory and 1 for PoS than I whould choose to
have 2 roles (inventory and pos) so that each client app have only the
hability to work with it's set of db objects.

If I need admin user that have the rights for inventory and pos, I *can't*
simply grant both roles to it because users whould not be happy having to
log with just one or another and it would be useless for a client app.

And also, I *can't* create a role 'admin' and grant 'inventory' and 'pos' to
it (that whould be a nice solution).

SO, I have to grant ALLLLL the same rights from POS and INVENTORY to a new
role ADMIN... It's fine but a lot more work and a lot *harder* to manage
user rigts, since...

Lets say latter you have to revoke some right from POS, than you must
remember to do the same with ADMIN role. Let's say you have a new table you
must grant access to role INVENTORY and than to ADMIN and so on...

I don't think at all this defeats the purpose of roles, I think it improves
it's current design.

BTW, Thanks for *all* imputs

=)


Best regards,
Anderson Farias