Subject | Re: Retrieve user informationen via SQL |
---|---|
Author | Adam |
Post date | 2006-05-11T23:46:24Z |
--- In firebird-support@yahoogroups.com, "Robert Zimmermann"
<RobertZim@...> wrote:
roles, and those roles are granted permissions to insert / delete /
update / execute etc to the different database objects.
I would suggest you do not reinvent the wheel. There is already an
interface that wraps the API with C++ classes, so look at that before
you spend to much time.
However this is optional. The code that is executed by the server is
actually in the field RDB$VIEW_BLR (a sort of compiled SQL), so it is
possible to remove the view source and retain a functioning database
(but don't do this unless it is absolutely essential, just letting you
know it may not always be present).
Adam
<RobertZim@...> wrote:
>Users are registered to a server, not a database. Users are granted
> Hello @all!
>
> I'm just hacking together an easy-to-use database interface for firebird
> using C++ and ADO. I'm currently working on a code to retrieve different
> informations from the database. Since ADO functionality is sometimes too
> driver-dependant (OpenSchema f.e) I wanted to use the system tables of
> firebird. I can't find no system table for:
> a) all registered users
roles, and those roles are granted permissions to insert / delete /
update / execute etc to the different database objects.
I would suggest you do not reinvent the wheel. There is already an
interface that wraps the API with C++ classes, so look at that before
you spend to much time.
> b) users loggend inI do not believe this information is stored.
> Is there a way to retrieve such information using SQL ?
> And there's anotherto get
> problem regarding the views: Is a views sourcecode stored somewhere I am
> able to retrieve it by SQL? I saw a couple of tools that were able
> the sourcecode of my view but I couldn't find it in any of the systemRDB$RELATIONS.RDB$VIEW_SOURCE
> tables.
However this is optional. The code that is executed by the server is
actually in the field RDB$VIEW_BLR (a sort of compiled SQL), so it is
possible to remove the view source and retain a functioning database
(but don't do this unless it is absolutely essential, just letting you
know it may not always be present).
Adam