At 11:36 PM 09-09-02 +0000, you wrote:

>I managed to sort out the problem.
>
>It seems that Interbase Workbench and IBOConsole do not
>work as well as ISQL. I do not really know why.

When accepting DDL, isql opens a separate transaction for them and
autocommits. You can get the same effect by running a script with SET
AUTODDL ON preceding the statements. A script is the correct way to set
permissions.

>Some of the commands work after I commit with Interbase Workbench
>and IBOConsole, but some too do not work at all, whereas they are
>okay with ISQL
>
>As I am planning to use IBObjects in an application I wonder whether
>everything will run smoothly, and how I will have to set things up
>if commands are going to be as reliable as ISQL.

Nothing you do with Firebird or Interbase will run smoothly if you don't
take care of transactions, one way or another. This isn't a bug, it is "as
designed". If you run DDL commands and they fail, it is because of an
error in either (1) your statement or (2) your rights or (3) dependencies
relating to other users or transactions.

>This brings me to another problem I found.
>
>After granting table rights to a role 'WITH GRANT OPTION' a user
>added
>to the role cannot grant rights that are supposed to go with the role,
>even though the user logged on with the role.
>
>The following error appears:
>
>SC ERROR CODE:335544351
>
>ISC ERROR MESSAGE:
>unsuccessful metadata update
>no S privilege with grant option on table/view AFCREDIT
>
>Statement: GRANT SELECT ON AFCREDIT TO MIKE
>
>Is this a known bug or feature?

It's an integrity feature. What you need to do is sort out your
transactions. If SYSDBA in one transaction gives some grants to MIKE, then
MIKE busy in another connection and transaction will cause the update to be
deferred until MIKE logs off the system.

Follow the Golden Rules when performing DDL: do it by script and run the
script when all users except the SYSDBA or Owner are logged out.

heLen