Dmitry, with due recognition that you believe you know everything
worth knowing, let me remind you that I am the original author of ISQL
and at the time that I wrote it, neither isc_dsql_execute2 nor stored
procedure existed, so your claim that "this is what our poor ISQL has
been doing from the very beginning" is a tad weak.

Dsql was written as a clone of the DB2 API, circa 1985. As interfaces
go, it's absolutely terrible. Almost any change to the API introduces
in compatibility. Simply stated, fixed data structures shared across an
API are disastrous for upwards compatibility.

May I recommend that the next time somebody wants to make an
incompatible change to DSQL, don't. Instead, create a new API that can
be extended in an upwards compatible manner. The base DSRI / OSRI /
GDS/ ISC/ Firebird API has worked out quite well, as have SQL-based
APIs. There are many to pick from or to use as models. Put the ugly
DB2 API out to pasture as a legacy interface and find or build something
you can live with.

isc_dsql_execute2()

On 10/15/2010 2:55 AM, Dmitry Yemanov wrote:
> Jim,
>
>> I don't understand what the problem is. A thin DSQL layer might not
>> have any idea of what a particular SQL string might do under after the
>> statement is executed. If it produces results, then it can use
>> isc_dsql_fetch to get them. Expecting a command line interpreter to do
>> a semantic analysis of a user supplied string is a little harsh...
> All the required semantic analysis is to ask the prepared statement for
> its type and check whether it's isc_info_sql_stmt_exec_procedure. If so,
> call isc_dsql_execute2() instead of isc_dsql_execute(). This is what our
> poor ISQL has been doing since the very beginning.
>
>> That aside, does it really make sense to remove documented functionality
>> because it offends your sensibilities?
> The problem is that it doesn't work as documented. The API guide says
> that if isc_dsql_execute2() is called without output sqlda, then a
> result set is created and you need to call isc_dsql_fetch() to read the
> values from the result set. Sounds logical. However, in fact, a result
> set (aka cursor) is never created for EXECUTE PROCEDURE. The statement
> pretends to look like a cursor and allows you one and only one fetch.
> After that you'll be getting unexpected runtime errors. If you want to
> avoid these errors, you should be clever enough and look at the
> statement type in advance. So the minimal semantic analysis seems to be
> required anyway.
>
> Maybe it's just me, but I see a problem asking for a solution here
> (read: it offends my sensibilities). And I have a feeling that fixing
> the code to be in sync with the documentation (i.e. create a cursor for
> such statements) is wrong in this particular case. Hence a call for
> opinions.
>
>
> Dmitry
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376