Vlad Horsun wrote:

> SUSPEND you mean, not suspect ?
>
>
>

Indeed. What the senator meant to say was "suspend".

>>If someone wants to get cute and put a suspend where it doesn't belong,
>>he will get something unpredictable, which is only justice.
>>
>>
>
> How this differ from current situation ?
>
>Now: if developer don't put SUSPEND and do SELECT he has no result
>"which is only justice", imho
>
>

Exactly. That is a pointless thing to do.

>New: if developer put SUSPEND like this - IF(<false condition>) THEN SUSPEND
>"he will get something unpredictable, which is only justice"
>
>

No, of course not. The compiler sees "suspend". It's not at all ambiguous.

> Where is solution ? In any case we don't declare that procedure must
>have resultset. By the way - what is resultset ? Is empty set is valid resultset
>
>
>

Perhaps I've missed something important, but the only reason for a
procedure to contain a "suspend" is to return a record, and a procedure
that doesn't contain a "suspend" can't return records, so it isn't the
least ambiguous.

The difference is that the decision is made by the compiler. Nobody
else has to understand the blr, or where the blr would have been if we
hadn't trashed it in favor of something slightly more up to date.

>I see 2 ways we can go :
>a) JDBC will do SELECT from SP and Java developers will write right SP's
>b) we invent declarative way to force SP to return not empty resultset and
>raise error if SP don't return it, for example
> CREATE PROCEDURE xxx (...) RETURNS (...) WITH RESULT
>or even
> EXECUTE PROCEDURE xxx RETURNING ... WITH RESULT
>but it seems ugly for me
>
>
>

I don't see any reason that Jaybird can't support both types of
procedures correctly and transparently without changing or extending
syntax. I wouldn't have designed procedures the way Borland did, but
it's done, and it's better that we live with it than upset everyone and
change the syntax for no great benefit. We have all the information we
need to tag procedures by type in the metadata at procedure definition time.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376