> I could create a parallel table into the database, with the username
> and types allowed, which would need to somehow synchronize with the
> user DB (ISC4.GDB) so when a user is deleted there, then it is
> deleted from the parallel DB (via the admin applet). The admin apps
> beeing the only one requiring 2 db, the client relying only on the
> main db

> OR

> I could expand the user DB (ISC4.GDB) so everything related to a
> user would be stored in the same place. It requires access to 2
> different DBs (a hot topic lately) by the client, and could bring
> other surprises I'm not aware of yet.

I would largely ignore ISC4 and embed the necessary table in the
database where the information is needed. This will simplify the
application, because it wont need the second connection.

Updating ISC4 still wont store all user info in one place, there is
the database specific RDB$USER_PRIVILEGES table (and various other
owner fields etc). As for synchronisation with ISC4, dont panic, IB/FB
does not bother :-(

Just setup your admin applet with a "resync" button that will attempt
to clear user details when they no longer exist.


You may be better of associating the access with roles - roles are
entirely specific to the individual database, so there are no
synchronisation issues (other than the ones that IB/FB dont bother
about).

If you are using Firebird RC1 or later then you may even be able to
avoid setting up special tables. Just setup a views that select
according to CURRENT_ROLE - although this may not give you the
flexibility that you desire.


--
Geoff Worboys
Telesis Computing