Subject | Re: [Firebird-Architect] Re: rdb$db_key in either XSQLDA or XSQLVAR |
---|---|
Author | Jim Starkey |
Post date | 2004-04-30T11:27:58Z |
Roman Rokytskyy wrote:
to be modified to take advantage of the dbkey. But to do so it will
probably have to parse the dbkey (for join), in which case it needs to
know the lengths of the dbkey constituents, requiring a pass through
RDB$RELATIONS to pick the appropriate RDB$DBKEY_LENGTHs (or whatever I
called the silly field). For what it is worth, DSQL does this beneath
the covers when it generates a BLR request, but it doesn't have anyplace
to put this or to tell you how to use it.
>This would either mean to rewrite SQL query in the driver or to modifyRoman, it's not that simple. The application program is going to have
>the application. rdb$db_key does not belong to the application data
>model, has no meaning there and, I believe, should not be visible by
>the application in general. Rewriting SQL in a driver is not what I
>want. I believe that driver should be dumb and act as a simple
>interface converter, not to do work that belongs to the database server.
>
>
>
to be modified to take advantage of the dbkey. But to do so it will
probably have to parse the dbkey (for join), in which case it needs to
know the lengths of the dbkey constituents, requiring a pass through
RDB$RELATIONS to pick the appropriate RDB$DBKEY_LENGTHs (or whatever I
called the silly field). For what it is worth, DSQL does this beneath
the covers when it generates a BLR request, but it doesn't have anyplace
to put this or to tell you how to use it.