Lukas at al.,

thanks for your answers!

> >So I wonder who is mixing something up: Interbase or me?
> >[Usually, it's silly me.]
> I'd guess, Interbase.

Whew, a helpful hand for my busted self-confidence!

> I had the very same behaviour half a year
> ago, unfortunately in a very complex stored procedure so it took
> me a day to find out what was wrong. The only solution was
> to set the Variable to NULL before the select.

Yes, I thought about this, too, and it would obviously solve the issue.

> On the other hand, it is disputable if this is wrong behaviour:
> A select that does not return anything DOES NOT RETURN
> ANYTHING, not even NULL, just leaves the result vars as
> they were before. I'd guess that this is the technical background,
> and the fact that we're normally getting NULLs for "empty"
> selects in clients has to do more with how the column
> data stuctures are initialized on the client than with
> the Interbase engine actually returning NULLs.

You are right, but I would like to know if this should be logged as
a bug. Perhaps one of the FB developers could comment on this?

Interbase behaves differently in two situations which are almost the
same.

1) When doing a SELECT outside a stored proc, it returns NULLs.

2) When doing the same SELECT inside a stored proc, it leaves the result
variables untouched, they are not NULL.

For me, this is not consistent behaviour.
So one might call it a bug, not a serious one, but still a bug.


Any objections?


Christian