> M> EXECutable procedures can have output parameters just fine.
>
> ...so calling them through select won't hurt. ;-)

Except if there's no SUSPEND in them. Try this:

SET TERM ^^ ;
CREATE PROCEDURE CALL_TEST returns (
POOUT Integer)
AS
begin
POOUT = 1;
end
^^
SET TERM ; ^^

commit;

select * from call_test

--> no rows returned.

> M> What we really need ( I agree somewhat with the proposal ) is the
> M> server saying, "well, here's a resultset. It's not a SUSPEND inflicted
> M> resultset, so there's only 1 row." and "well, here's a resultset. It's

a

> M> SUSPEND inflicted resultset, so there might be more rows."
>
> Mmm... I don't think so. A mechanism for signaling when a resultset is
> finished already exists, the client just has to "fetch until eof".
> What Roman is missing (as I understand) is something to help telling
> what kind of call syntax to use *beforehand*. As I explained, I think
> it would be useful but I don't find it strictly needed as we already
> can do without.

Naah, don't agree here. And Roman doesn't agree either, because he is
facing the same problems as we all do.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com