At 05:26 PM 12/04/2004 +0000, you wrote:

>Sorry, my mistake for the misunderstaning.
>
>ADMIN_ROLE has been granted read/write permission for a whole stack of
>tables and read permission for others.
>
>After creating the role ADMIN_ROLE, I granted the role these
>permissions (which are stored in the DB, I did check RDS$USER_ROLE or
>some such table).
>
>So when a user "foobar" does perform a "mock" login, I would like them
> to be granted the role of ADMIN_ROLE.
>
>If I set up a connection object with my app that connects as SYSDBA
>and grants this "mock" login the role ADMIN_ROLE, it does not seem to
>have any effect (a query fails saying "foobar" does not have read
>permission blah blah)
>
>I thought maybe in Firebird embedded the
>
>GRANT <role> to <user>
>
>seems to have no effect, or should it?

No.

What's needed (not in your application) is for SYSDBA to
1. CREATE ROLE ADMIN_ROLE
COMMIT;
2. GRANT <privileges> ON <things> to ADMIN_ROLE
(as many as it takes, and COMMIT)
3. GRANT ADMIN_ROLE TO FOOBAR( and commit)

Then that setup part is done. SYSDBA is not involved any more.

Now, when foobar logs in, he has to have ADMIN_ROLE in his connection
parameters.

/heLen