Subject Re: Retrieve user information via SQL
Author Adam
> 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.

would be a very good place to start.

> >
> > 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
> 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
must be submitted by the usual 'alter procedure' ddl.