> Hm ok, it's just because I saw something like that on oracle (a

system view

> showing all users as far as I remember).

Oracle <> Firebird

In Firebird, users are a part of the server. In Oracle, I have no idea.

>
> > 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.
>
> Right, but I wanted to have a fully functional interface that is

capable to

> connect to other databases as well. And so I'm writing a) a common
> base-interface and b) changeable .dll "plugins" for database

specific stuff

> (like the database information retrieval I mentioned before). This

also is a

> learning project. I'm interested in how all that database stuff

works. Sure,

> somebody has done this before.

That changes nothing. Then you write a changable dll plugin
base-interface thing that wraps around the hard work others have
already done. That is the basis behind OOP.

http://sourceforge.net/projects/ibpp/

would be a very good place to start.

>
> > RDB$RELATIONS.RDB$VIEW_SOURCE
> >
> > 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
>
> Ok thanks. I just wanted to retrieve the code to alter it using an

editor.

> So I guess it's okay. I never would modify the system tables myself.

Absolutely not, playing with system tables is a good way to make
spaghetti out of your database. In case I was not clear, you can READ
BUT NOT CHANGE the field RDB$RELATIONS.RDB$VIEW_SOURCE. Any changes
must be submitted by the usual 'alter procedure' ddl.

Adam