Dmitry Kuzmenko wrote:

> RR> Wrong. Programmer writes following code:
> RR> CallableStatement stmt = connection.prepareCall(sql);
> RR> stmt.registerOutParameter(2, Types.INTEGER);
> RR> stmt.setInt(1, 1);
> RR> boolean hasResultSet = stmt.execute();
> RR> At this point me, as driver developer, has to decide whether to use
> RR> SELECT * FROM or EXECUTE PROCEDURE. How?
>
> by procedure code. This code have nothing about what you call - pure
> select, update, delete or execute. You can execute anything (and DDL
> too). You can write select from proc or execute procedure proc. This is yours,
> database developer, decision. Based on - procedure output params
> existance and suspend inside procedure code.

Dmitry - please bear in mind that Roman is looking at this from the
point of view of an interface, NOT the end user. I have a similar
problem with the PHP stuff. It's OK going one way or the other when you
are designing the SQL, but when someone else is feeding unknown SQL into
an interface (Java, PHP etc.) THEN we need to know what the SQL consists
off. The point that Roman is trying to make is that as a bridge
component we don't know what IS in the stored procedure, so you don't
know how to handle it! All Roman is asking for is some way to know how
to handle this situation?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services