Here is a suggestion that would not require BLR changes or new variables
that are non-standard.

It is not perfect so keep the flames low...

A new system view is created. Selecting from the view returns a result
set of multiple rows of two (or more fields).
The two fields are (GLOBALVAR integer, GLOBALVAL varchar(31))

The view is a select from a stored procedure that selects from a
underlying table that holds all the current settings for every user.
(from what roles they have to their current connection information).

The default stored procedure will only select the information that is
for the current user, but a developer could re-write it as neccessary
for any level of security since the stored procedure can read the entire
dynamic table.

When a user starts a transaction, the values are entered into the
dynamic table.
That information needs to be publically viewed, even if the transaction
is not commited. When the transaction finishes /connection is lost, the
appropriate record is removed. Only inserts/selects/deletes are allowed
on the table.

This is dangerous, and I am sure alot more thinking needs to be done for
it, but, it does remove the need to keep playing with BLR when new
global variables are needed. It also would allow a stored procedure to
know who is logged on and for how long.

best regards

Dalton

Jim Starkey wrote:

>
> At 05:09 PM 4/18/01 -0400, Ann W. Harrison wrote:
> >
> >
> >OK, so how would you represent multiple roles? For logging,
> >for example... ?
> >
>
> [Nothing like communicating with a person three and a half feet
> away through a list server...]
>
> The existing mechanisms for passing data from server to client are
> these: a) Info calls (request, transaction, database), b) blr
> value expressions and the ilk, c) results sets from system
> tables, pseudo system tables, stored procedures, and the like,
> d) system defined "udfs".
>
> The info calls are dandy, but require that the transaction
> handle and API be exposed and that he host language be able
> to handle gook. I like 'em, but I'm probably the only one.
> Let's count them out.
>
> Blr value expressions eat into blr space, require non-standard
> SQL syntax to support them (oh, look, Jim is arguing against
> non-standard!). They also don't lead to returning complex
> data (multiple role, each with active indicator).
>
> Semi-magic result sets are the accepted way to handle this sort
> of crud in ODBC/JDBC. They're easy to define and easy to extend
> when you discover that you forgot something. On the other hand,
> if there are lots of nasty little items to support you either
> have to give the user everything (is this really a problem?)
> or invent some mechanism to say what you want. Doable, but
> maybe more mechanism that you want to invent. On the other
> hand, "semi-magic" result sets a la ODBC/JDBC require additional
> API calls, extensions to remote protocols, version skew, etc.
> Pseudo-system tables (tables real or imagined) are preferable
> (if the ODBC goons could have agreed on name space issues, they
> probably would have done this).
>
> System defined UDF, like the doomsday function but without
> the side effects, would be easy and embeddable in stored
> procedures. On the otherhand, I'm about the only person
> who doesn't like Interbase stored procedures, so I'm not
> particularly enamored with this solution. A more rational
> person might want to run with it, however.
>
> We can probably invent some alternatives. Netfrastructure
> has a neat mechanism to open a "service connection" into
> a server to import executable serialized object clusters
> for interserver communication. But that requires embedded
> Java...
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/