At 05:39 PM 6/29/00 +0200, you wrote:

>
>| Actually, the engine doesn't use SQL but BLR. DSQL translates
>| dynamic SQL to BLR, QLI generates BLR natively, gpre generates
>| BLR from SQL at compile time, and DUDLEY (gdef) generates stored
>| procedures and triggers in BLR.
>
>The following question it not related to the current discussion, but I jump
>on it, just because I'm curious.
>
>Does this mean that the server do not parse any SQL statement any time ?
>Are DSQL statements (DDL or DML) submitted through the C-API parsed at the
>client-side and are the actual network requests to the server done in BLR ?
>

Up until version 4 this was correct. Dynamic SQL has handled by
a client side library (DSQL). In version 4, DSQL was moved from
the client to the engine to both reduce the amount of client side
code and to be able to share the cost of fetching and maintaining
meta-data among all users. But by and large, DSQL is outside the
[engine] box, generating BLR and using the internal version of the
published API.

The optimizer, in specific, never sees SQL, only an internal
representation of BLR.

This does not imply any inefficiency -- the output of the semantic
analysis phase of DSQL is BLR rather some other arbitrary data
structure. It does, however, isolate the inner workings of the
engine from the foolishness of the various SQL standards committees.

So, from the client's point of view, SQL processing is done in
server. From the server's point of view, SQL processing is handled
in DSQL rather than the engine itself.

DDL is a different story. The real DDL operations are performed
by ordinary DML to the system tables. SQL DDL is what is known
in the biz as syntactic sugar.

Jim Starkey