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
a
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 isn
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 o
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 on
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 in