Roman,
an example at last! Although the stored procedure code is missing. ;-)

R> CallableStatement stmt = connection.prepareCall(sql);

R> stmt.registerOutParameter(2, Types.INTEGER);
R> stmt.setInt(1, 1);
R> boolean hasResultSet = stmt.execute();

R> At this point me, as driver developer, has to decide whether to use
R> SELECT * FROM or EXECUTE PROCEDURE. How?

Since it has an output parameter, you just go the safe route and use
SELECT. This means than a SP that returns a single row would be seen
as returning a resultset (not strictly correct). Is that a problem for
you?

R> In some previous post you wrote that this is mistake of a developer
R> not to put SUSPEND into the procedure that is meant to be used with
R> SELECT * FROM statement. Probably you're right if we assume that
R> people work only with isql. But as long as some component (especially
R> those build according to some specification) comes into play, things
R> are not so nice anymore.

This doesn't make sense or I can't get it. I don't know what does isql
have to do with the issue at hand and the last sentence is, well,
useless. Can you explain why is a necessity to accept that people do
things against documentation and write stored procedure with RETURNS
clauses but without SUSPEND statements?

Ciao
--
Nando Dessena
http://www.flamerobin.org