Hello Nando,

> >> FWIW you could look for output parameters in the SP declaration and
> >> use the "select" form if you find any. That's what FlameRobin does.
>
> M> Huh? How should that work?
>
> It wouldn't work only if a SP had output parameters and you forgot to
> put a SUSPEND in, but in that case it's assumed that's your fault. For
> all the other cases, it's assumed that a SP that has output parameters
> is selectable.
>
> M> btw, I'm looking for a SUSPEND in Database Workbench and use
> M> SELECT to "run" the procedure then.
>
> Well the suspend could never be executed anyway, depending on the
> program flow. Plus you need to parse the code (if you want to make it
> robust, at least - you wouldn't want to catch suspends in comments or
> literals by mistake, would you?)

All taken care of ;-) ... That being said, it only works for procedures
that have source code :-)

>and I don't think that's appropriate
> for Jaybird. Checking for output parameters is simpler, quicker and
> at least equally effective.

Well, for a client tool, it's not really a problem, I guess. On the other
hand, EXECutable procedures can have output parameters just fine.

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

With regards,

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