Ann wrote:

At 12:12 PM 4/19/2001 -0400, Leyne, Sean wrote:

>I think that pseudo tables could have
>some good benefits but in *conjunction* with the 'functions' we have
>been talking about - you should not have to perform a SELECT to get the
>information about your connection from within a trigger or SP.

Oh, sigh. Two mechanisms - one result. Or more likely, two
mechanisms, two vaguely related results.

/
Maybe it's my naivety, but I don't see how the results would be
_vaguely_ related. To my mind, the contents of the pseudo tables, would
be the exact representation of new server/connection objects which would
be initialized on connection start. Accordingly, I don't see the
"vagueness"

>As Diane will probably point out, SQL does not allow for multiple user
>roles.

Somehow I suspect we will run into other information that doesn't
resolve to a single value. Transactions, for example ... a
cross-database
transaction has at least three transaction identities - one for each
database and one for the combination....

/
In this case, I saw there being multiple system pseudo tables - one for
connections and another for transactions (with a foreign key to the
associated connection). Obviously, the pseudo data would need to be
appropriately normalized.

Accordingly, I don't see a "multiple entries" problem in this case,
although I do understand your overall point.

With respect to the blr_scalar_function, I thought that's what you
meant, just wanted to be sure.


Regards,

Sean

---
Your database needs YOU!
http://firebird.sourceforge.net/