Subject Re: accessing system information (was "planning the use of blr codes" )

> 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

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

Upscene Productions

"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
> 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