Hi Claudio, others,

Please remove email addresses when quoting messages, this is an
emailing list with a public archive and I get about enough spam
already, thanks :)

> > What about a views with:
> >
> > - connected users
>
> Connected users is the same info that you can get through
> isc_database_info,
> provided that you don't get a truncated list, of course. :-)
> (Thread "User list truncated").

*g*

> Of course, with that, you get a list, not that you are going to change
> anything.

When having a view, you can get it SQL based, the proper way of
doing it, IMHO.

> > - queries (states: preparing, busy (ordering etc),
> fetching, suspended)
>
> The state may be so volatile that I don't know if it's a
> performance hog to
> maintain it. Our prepare phase is really fast.

Prepare yes, but nevertheless, as a diagnostic tool, it would be
nice to know what sessions (connections) or queries are currently
running in, for example, a long SORT phase. And if you could cancel
these, it would be even better.

> > - processes (users, threads, sweep, backup, etc?)
>
> Provided that you don't want to see thread in Classic. <g>
> Backup is no more than gbak connected with a special dpb.
> Anybody can lie
> and pretend to be gbak.
>
> > Deleting from connected users would really disconnect,
>
> How is this different than to take the db in single user mode
> with gfix?
> That you want to drop only specific users?

Yes, dropping specific users that are running, for example, wild
statements, eating server resources and bugging other users -
sometimes, a SYSDBA really wants to drop such a user to get things
going again.

> > SYSDBA and DB owner only? How hard would it be for a non-C
> > programmer (me) to get these kind of things started?
>
> To get what started? I don't get the idea. To do client-side
> support or to
> get your hands inside the engine's code?

To get your hands inside the engines code. I'm really interested
in (virtual) views for these kind of things... It's probably very
hard and I do not have that much time - but I do have some ideas
about new features (spread on this list, firebird-devel,
ib-architect) and I sometimes have the idea that I'm just having
ideas only and do not contribute a lot to FB.

> > How
> > hard would it be to create these kind of views, Claudio??
>
> It depends on how much money the community wants to chip-in
> for this humble developer, Martijn.
> :-)

*g* ... btw, is there are doc yet where we can have a look at
where FB2 is heading?

> > And is it possible to create users via SQL statements (SYSDBA
> > only?) instead of the (juk) services API? How hard would this
> > be?
>
> AFAIK, Greg Deatz was exploring those roads in his
> FreeUDFLib. He built a
> function so anybody could change his/her own pw, without sysdba.
>
> It seems that people really hate the Services API. What's the
> exact reason?

I find the services api very cumbersome to use. The IBX components
that use it are simply... well, how can I put this mildly... ah
well, I can't ... they suck - they hardly conform to ANY naming
convention in Delphi. Whenever something goes wrong, they lose
connection (don't know if it is the components or the API itself).

And, as said before, I like a SQL interface for about every
operation - including user lists, creating/dropping users etc.
Even the server log as a system view would be nice :) This would
also be easier to empty the log remotely as I haven't found a way
to do that yet...

So, if it comes to API or SQL I would certainly choose for SQL
for everything!


greets,

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com


[Non-text portions of this message have been removed]