Anderson Farias wrote:

> H> Hmm, you apparently don't understand the purpose of roles.
> H> A role is a package of permissions. Once the package is
> H> set up, then the role is granted to each user that
> H> requires those permissions.
>
> One thing I can't understand about Firebird roles is WHY do you need
> to "set" one at client connection. If you've already granted
> the "package of permissions" (roles) to the user, and the DB already
> know about it, why on the earth do the client has to set this
> information for the connection? That's quite annoying.
>
> I wished this worked in a more "smart" way... when connected the user
> would just have access to everything already granted to the user and
> (all) it's granted roles.

Anderson,

You still don't seem to understand the purpose of roles.

For Firebird, it is useful to think of roles as one of many hats you can
wear and that they are specific to a database connection. As an
individual I can act as an end user or as a database owner or as the DBA
in charge of the database server. When I connect to the database I pick
which role I will be acting in and select that role for the connection.
If I pick my end user role I will be rather severely restricted via the
rights granted to me during that connection. If I pick my database owner
role (using the same username and password) then I will find I can do
much more with the database during that connection.

The fact that I have been granted the ability to use these roles at any
time does not mean I can connect and use the abilities they grant me all
at once during the same connection. I still have to pick in which role I
will be acting each time I connect.

Roles are not groups that my username belongs to and from which my
account inherits rights. That is a different concept (although for other
products it may go under the name of "roles").