i have a database created and access on Firebird for years.

i've always used the id/pw sysdba/masterkey

all i want to do is:

change my delphi IBO Objects tIBConnection.username to 'mynewuser'

and .password to 'mynewpassword'

i am not sure what to use in .SQLROLE?  i've tried 'RDB$ADMIN'  and leaving it blank 

on the computer with the database? using gsec i've run:

gsec -user sysdba -pass masterkey -add mynewuser-pw mynewpassword -admin yes

< p="">now,

Helen Borrie: Don't know what you are expressing here, but a password is a string and double quotes are not valid characters in that string.

when i try and connect the TIB_Connection, i get this error message:

"could not open tableA table

isc error code 335544352

no permission for read/select access to table tableA"

Helen Borrie: It means exactly what it says.  You new user does not have the required privileges on tableA and obviously you didn't log him/her in with the RDB$ADMIN role.  You have to include that in the login credentials to access the privileges associated with it.  That form of granting the RDB$ADMIN role makes it available to the user in all databases, which might not be your intention.  Better to GRANT ROLE RDB$ADMIN TO <user> for a specific login, e.g., when the user is going to perform a Services operation such as gbak and make another role granting specific privileges on specific tables.

no surprise, i've got a customer that doesn't want to use the sysdba/masterkey connection id/pw 

Helen Borrie: I like it when customers clearly know what they're doing.  The whole world knows 'masterke' as the default password for full destructive access to Interbase and Firebird databases.  

so all i'm trying to do is add a new one...

i've google the heck outta this and can't figure it out.

Helen Borrie: Why not just read the documentation available on the Firebird website?  There's a user manual for gsec there.  There's also a language ref with the CREATE USER and ALTER USER syntax, for servers 2.5 and above and databases ODS 11.2 up.  If your database and/or server version is older, the RDB$ADMIN role isn't supported...well, AFAIR, some higher versions of 2.1.x did so, possibly due to a back-port.  In any case, use SQL privileges rather than throwing superuser privileges around willy-nilly.

Anyway, if you do have RDB$ADMIN support available, put it in the SqlRole property of TIB_Connection for any connection for which he needs it.  If you don't, then work out a nice neat scheme of roles.

what am i missing?

Helen Borrie: It's going to be of benefit to get your head around the differences between destructive rights and SQL privileges.  Note, too, that it is possible to grant privileges to a user directly.  My advice is to use roles ALWAYS, as it keeps the privilege in nice neat packages that you can apply on a per-connection basis.  It can drive you insane trying to sort out a privilege scheme that was thrown together as a melee of user-directed and role-directed.  One does not overlap the other and it is easy to create a nightmare.

HB