>>>>> "Helen" == Helen Borrie <helebor@...> writes:

Helen> At 11:37 AM 30/10/2003 +0100, you wrote:

>> Hi all,
>>
>> we are experiencing a very strange situation where the firebird
>> server crashes with an ISC ERROR CODE of 335544741. We have
>> tried almost everything, and with every FB recent release (ie,
>> 1.0.3 thru 1.5RC4), but without luck. We are still wondering if
>> it's a FB related bug

Helen> No

Well, I could imagine a stronger server that does not crash... :-|

>> or if it's raised by a client app with a bad behaviour.

Helen> Bad SQL syntax..
Helen> The problems: First, lack of column identifiers:

Ok.

Helen> Next, a join with no join conditions. You have to join one
Helen> set ON another set by way of a linking key and you should
Helen> usually have columns from both sets in the SELECT list --
Helen> otherwise there's not (usually) a reason to have a join at
Helen> all (how can the optimizer make a river out of one
Helen> stream?).

Helen> You can't join a table to a stored procedure that doesn't
Helen> generate any output. It has to be a selectable SP with its
Helen> output row specified in the RETURNS clause of the SP and
Helen> its rows being output by means of a loop that calls
Helen> SUSPEND.

Helen> If any of the meantioned features aren't present in your
Helen> SP, then you are in server-crash country. If they are,
Helen> then press on...

Helen, the SP is ok with these "constraints". And, even if it's not
documented, I used to use such a construct since IB 5.x... Some of my
SPs are somewhat like a function: they take some arguments and emits a
result dataset. There's no point using another expression to link the
result back to the arguments' source. As other stated here, the form

CREATE PROCEDURE details (arg1 INTEGER, arg2 INTEGER, arg3 CHAR(1))
RETURNS (code INTEGER, description VARCHAR(30)) AS
BEGIN
FOR SELECT t.code, d.description
FROM table t
JOIN descs d
WHERE t.key1 = :arg1 AND t.key2 = :arg2 AND t.key3 = :arg3
INTO :code, :description DO
SUSPEND;
END

SELECT sp.code, sp.description
FROM Table t
LEFT JOIN details(t.Field1, t.Field2, 'A') sp ON 1=1

*has* and *is* working ok (and **fast**) on all released IB/FB
servers.

Iff what you meant is that this is not recommended, well, I'm in big
trouble!-(

Helen> followed by a whole heap of stuff that ought to be in a
Helen> stored procedure, not walking all over a whole heap of
Helen> derived data that's sitting there in an uncommitted state.

Yes, you are of course right here. But the server should not core
dump, or at least should give some more hints that "terminated
abnormally". I forgot to say that this happens both under Windows and
on GNU/Linux...

Thanx a lot!

bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@... | -- Fortunato Depero, 1929.