Subject Re: [IBO] problems with joins involving stored procedures
> 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
> 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
> the server dies with a memory access error. (Of course, only some
> 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
> 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
> deliver an incomplete or wrong plan for the user that wants it.
> 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.


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