Hi Alan and all,
Thanks for this further insight into your approach. I am quite new to FB, but
from what I have read I am wondering a few things with this approach. First
looking at Borrie's 2nd edition (p. 729):
"From Firebird 2.0 onward, the USER table is replaced by one named RDB$USERS
Hi Alan and all,
Thanks for this further insight into your approach. I am quite new to FB, but
from what I have read I am wondering a few things with this approach. First
looking at Borrie's 2nd edition (p. 729):"From Firebird 2.0 onward, the USER
table is replaced by one named RDB$USERS and
Thanks for this Alan.
Unfortunately when connected under the ROLE RDB$ADMIN, this still results in an
error as RDB$USERS is an unknown table. Same goes for replacing this with
USERS. As stated in Helen Borrie's The Firebird Book (p.729):
"From Firebird 2.0 onward, the USER table is replaced by
Thanks for this Alan.
Unfortunately when connected under the ROLE RDB$ADMIN, this still results in an
error as RDB$USERS is an unknown table. Same goes for replacing this with
USERS. As stated in Helen Borrie's The Firebird Book (p.729):"From Firebird 2.0
onward, the USER table is replaced by
In a production environment using Firebird v2.5, we need to delegate authority
of USER CRUD operations to more than one person without these admins sharing
the SYSDBA user and password.
These admins have been created as users with ADMIN ROLE, and are logged in
under the RDB$ADMIN ROLE (eg
