At 08:36 PM 28/03/2004 -0700, you wrote:

>Maybe the error is in the documentation you have, and no changes to your
>docs are required. :)

No...it's a bug that was supposed to have been fixed...

>Just makes little sense to me, that
>
>Create procedure SingleLine
>Returns (a integer)
>as
>begin
>a = 1;
>Suspend;
>end
>
>would not require a 'suspend' to return the result, and
>
>Create procedure SingleLine
>Returns (a integer)
>as
>begin
>for select val from table
> into a:
> do
> suspend;
>end
>
>does require it to return possible multirow results, if both called via a
>select.

You misunderstand what Suspend does. You are assuming it means "output the
row". It doesn't - the row has already gone to the cache when Suspend is
called. Suspend literally *suspends* execution while the procedure waits
for the next FETCH call into the cursor.

>what would the following procedure supposed to return, if called via a
>select ?
>
>Create procedure SingleLine
>Returns (a integer)
>as
>begin
>a = 1;
>Suspend;
>a = 2;
>end

Currently (with the bug) it would return 1. You can only get multi-row
output from a cursor. There is no cursor here, so there is nothing to wait
for. Suspend just drops control down to the final END statement: the
second assignment is never executed.

>As far as IBO, it all depends how many times you require to call a
>particular procedure. With all the differences between FB and IBO
>versions on calling procedures via an excute, you so nicely posted
>in one of your previous replies, it sounds less worrisome to just
>use a select :)

No, it's not a question of "less worrisome". A scrollable dataset isn't
logical to use for a singleton result: but you get all the scrolling stuff
all the same. IB_Cursor eats less than IB(O|_)Query because it doesn't
have a row cache. IB_SQL is cheapest of all - it's just a bare statement,
with no frills.

>Hope you saved a copy of your reply for your book, it was very
>useful information.

It's in the book already. It's an area that's been (a) neglected in the
documentation (b) misused in the sample databases and (c) subject to
bugs. I've got a sick server at the moment but I do want to run your
"reproducible bug" through 1.0.3 when I find and fix my problem (not a
hardware one but something obscure in Win2K network setup) to see whether
the info that it was fixed there was wrong. Regressed bugs are worse than
neglected ones! :-<

cheers,
Helen