At 04:38 PM 4/24/01 +0200, Ivan Prenosil wrote:

>
>Inquiry that can return more values (like databases participating
>in transaction, active roles ...) can be retrieved by functions
>with arguments, i.e. not simple USER, ROLE, ..., but
>
> ROLE(<value>)
>or
> blr_scalar_function, blr_function_role, <value>
>
>where <value> can be either index or handle.
>
>Once the info is available in that form, it is easy to write
>system-selectable-stored-procedure, and thus there is no need to invent
>new mechanism for pseudo system tables.
>
>(I expect that no one wants updatable pseudo system tables?)
>
>

An intrinsic problem with a blr solution is that the "database"
isn't a monolithic thing. A typical connection goes through
a client library, a remote interface, a communication subsystem,
a remote server, a Y-valve, and an engine. When retrieving
state information each of these layers as potential say.

The "info" calls -- gds_database_info, gds_request_info,
gds_transaction_info, and gds_blob_info -- are designed so
each transmission or service layer can toss its two cents
worth as appropriate. Requesting version, for example,
gives easily parsable versions for client, remote, server,
Y, and engine (and more if necessary). One place where this
is particularly important is transaction id for distributed
transactions where the Y-valve fetches transaction ids from
each particpating services, encapsulating the result.

If you need comprehensive state information, the blr guys
just don't hack it. I realize that there is a problem
exposing the handles required to fetch state information,
but if comprehensive state information is required, that
is going to have to be solved.

Borland has not been particularly respectful of the architecture
and has paid a penalty for it as they wrote off larger and
larger parts of the product set. Re-establishing the
Interbase architecture should be a priority and extensions
should be compatible with the architecture.

Jim Starkey