At 11:28 AM 6/29/00 +1000, Daniel_Work@... wrote:

>
>>Guys, don't even think about it. The engine is the wrong place
>>>for at least a million reasons. Believe me, parsing stuff is simple and
>cheap.
>>>Pick a SQL parser from almost anywhere in the product set and go at it.
>
>I don't understand the last sentence, are you referring to a third party
>SQL parser or Interbase's parser ?
>and if so I thought the Query engine contained the parser?
>

There are a number of SQL parsers scattered around, including
DSQL (dynamic SQL), QLI, GPRE, and probably a couple of others.
They differ by SQL dialect, user friendlyness, and integration
with the host environment.

But really, a SQL parser is a very simple thing. If you want to
make a custom tool, I suggest you build something that meets your
specific needs. There are two general ways to go at it. The
easiest may be YACC (or open source cousin BISON). Most professional
parser tend to be hard coded, recursive decent. SQL is such a trivial
grammer YACC is probably the preferred choice (DSQL uses YACC).

So if you're really lazy, pick up the DSQL YACC parser, replace the
error handling with something appropriate, and go at it.

>>>But, please, don't crud up the engine with stuff that virtually nothing
>to do with its job.
>
>All I'd like is a copy of some of it's data (assuming the query engine
>contains the SQL parser).
>I would like to use the internal SQL parser because I think it would
>guaranty the same answer to both the questions;
>* What do I need to execute this query?(Interbase)
>* On what does my Query depend?(Developer)

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.

Jim Starkey