Hi,

> While I quite agree with the need, how about an alternate approach.

I like this approach - it gives you much more information in an easy
way...

I guess there has to be some kind of SESSIONID keyword or so that
matches the primary key of the rdb$sessions table.

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

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."

> There is plenty of reason to expose more system information - and it
> seems a more useful way to expose it is via system pseudo-tables.
> Such a table would not be under transaction control, not exist
> on disk, but could be queried through normal SQL methods. (if

anything

> is
> normal in SQL).
>
> Totally off the cuff,
>
> create table rdb$sessions (
> rdb$session_id integer not null primary key,
> rdb$start_time timestamp,
> rdb$user char(x),
> rdb$role char(x),
> rdb$character_set char(x),
> rdb$client_name,
> rdb$protocol,
> rdb$address (etc)
> whatever else seems useful...)
>
> create table rdb$transactions (
> rdb$transaction_id integer not null primary key,
> rdb$session_id (references rdb$sessions.rdb$session_id)
> rdb$statements_executed, rdb$rows_modified, etc.)
>
> Heck, for that matter, perhaps these should be on-disk structures.
> (Ouch, No, I didn't mean it!)
>
> Dave