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...

That aside, does it really make sense to remove documented functionality
because it offends your sensibilities? Users have a reasonable
expectation the working programs will continue to work after an upgrade,
and tend to get upset when arbitrary changes are made that break their
systems. Something that was once well understood is that if you force
users to port their applications to a new database version, they just as
well might port their applications to a different database system
altogether.

One of the benefits of a clear and consistent architecture is that you
tend not to paint yourself into corners all that often. But when you
do, take your lumps, learn from the experience, and take the bullet for
the user.

If it's documented, works as documented, and doesn't block
implementation of an important new feature, live with it.

On 10/13/2010 1:52 PM, Dmitry Yemanov wrote:
> All,
>
> There was a private discussion going on for some time without getting
> anywhere close to the agreement, so I'd like to make it public in a hope
> to get more opinions.
>
> In all IB/FB versions, it's possible to execute apriori singleton
> statements (EXECUTE PROCEDURE, INSERT RETURNING) with either
> isc_dsql_execute() or isc_dsql_execute2(out_sqlda=NULL), i.e. without
> returning the output values in the same round-trip.
>
> I'm trying to understand how this behavior should be formally treated:
>
> 1) as correct and results should be discarded after execution
> 2) as wrong and error should be thrown (no room to store output values)
> 3) as an incomplete operation waiting for isc_dsql_fetch() to get the
> results
>
> Currently, the latter is true and it's even documented in the API guide.
> However, a fetch call against a non-cursor (such singleton statements
> don't create an internal cursor and IMO this is absolutely correct)
> makes no sense to me. Even if we'd try to utilize that fact and write
> some universal code that treats such a statement as a regular cursor and
> uses a common keep-fetching-until-EOS-mark approach, then we'd found
> that (a) the second fetch call results in a request synchronization
> error instead of returning the end-of-stream status, and (b) an attempt
> to use DSQL_close for that statement results in a "cursor is not open"
> error. Thus you must be aware that only one fetch can be performed and
> nothing else is needed (and I don't see this in the documentation).
>
> So, what are the benefits of allowing fetches against non-cursors in
> general but throwing errors for the common usage patterns? Was is to
> intentionally support option (3) above with a hope that users would
> figure out that only single fetch call is necessary? If so, why was it
> decided to be better than options (1) and (2)?
>
> Firebird 2.5 has disabled an ability to fetch from a non-cursor, so the
> only way to execute singleton statements now is to use
> isc_dsql_execute2() with a non-NULL output sqlda. This worked always and
> is expected to work forever.
>
> However, if you execute such statements without output sqlda, you have
> no chances to get the returned values. This may be treated as a bug and
> we have requests to restore the legacy behavior. I have to admit they
> are somewhat valid, as the disabled behavior was documented. It's
> trivial to restore the old logic, but it turns us back to the question:
> what is the point in choosing one bad behavior to replace another bad
> one? Maybe we could find a solution without drawbacks?
>
> Keeping the legacy background aside, I'd rather choose option (1) or (2)
> to be applied in this case. But maybe I'm completely missing the point
> and option (3) is really the good one. If so, I'd suppose issues (a) and
> (b) deserve fixing.
>
> Comments anyone?
>
>
> Dmitry
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


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