At 05:46 AM 25/03/2007, you wrote:

>Well,
>
>GRANT ALL ON <table> TO PUBLIC
>
>is the closest I know of. Of course, you could write a stored procedure
>that get all the table names using the query found at
>http://www.fbtalk.net/ViewTopic.aspx?id=139, add the GRANT ALL statement
>above before and after each table and use EXECUTE STATEMENT. But I don't
>think there is any statement that could grant all on tables not yet
>created, that is, unless you use the embedded version that I don't think
>use any user authentication at all (but then it isn't really multiuser).

The embedded version is a server model. The fact that the embedded
server bypasses *server-level* authentication makes no difference to
database access control. The same rules apply to access control
inside a database, regardless of the server.

Someone should mention that GRANT ALL ON <atable> TO PUBLIC merely
grants SELECT, INSERT, UPDATE, DELETE and REFERENCES privileges to
any user. EXECUTE permissions for stored procedures (including
selectable ones) and for ROLEs do not come in the PUBLIC package.

PUBLIC privileges, IMHO, cause more problems than they solve. It is
far preferable to create the ROLEs (which can be done with a
carefully prepared script in your favourite text editor, with
copy-and-paste) and then to grant and revoke the required roles as
required. The benefits are that your script acts as documentation of
the privileges that are available and that new roles can be created
subsequently to meet new conditions as they arise.

./heLen