> This has NOTHING to do with IB_WISQL or IBConsole intrinsically.

They only

> trigger a bug in the server: either IB or FB will die immediately.
>
> The reason is that both tools retrieve QUERY PLAN information. It's

possible

> to execute successfully some SQL queries if you don't ask the

server how it

> prepared the statement. However, as soon as you request plan

information,

> the server dies with a memory access error. (Of course, only some

plans

> fails or you would see the bug always.)
>
> We at Firebird know how the bug happens, but fixing it is not
> straightforward. The server generates a binary representation of

the plan it

> created (using byte code tags) and there's a routine that

interprets such

> info to convert it into human readable information, the "PLAN" line

(s) you

> see in IBConsole and IB_WISQL. The binary information is truncated

hence the

> routine that decodes it never finds the matching end (so it

continues

> advancing) and goes reading out of the input buffer limits,

producing a

> typical buffer overrun. Putting additional checks on the

interpreter code

> would stop the visible bug, but would hide the real cause and hence

would

> deliver an incomplete or wrong plan for the user that wants it.

Sincerely,

> since Borland implemented the "plan" thing, I would hope that they

will take

> a peek at it, assuming they are familiar with such code, because

the binary

> plan extraction is not necessarily a simple routine.
>

Claudio,

Thanks for the relatively detailed explanation of
what is going on. Understanding the interaction helped a
lot. I sort of suspected that The problem was with the
server, which should NEVER terminate abnormally, and
not IBOjects. IBObjects will most likely be the IB-Delphi
components I use in a upcoming project

Geoff