|Subject||Re: Retrieve user information via SQL|
> Hm ok, it's just because I saw something like that on oracle (asystem 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
> connect to other databases as well. And so I'm writing a) a commonspecific stuff
> base-interface and b) changeable .dll "plugins" for database
> (like the database information retrieval I mentioned before). Thisalso is a
> learning project. I'm interested in how all that database stuffworks. 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.
> > 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
> 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.