On 10/15/10 11:55, Dimitry Sibiryakov wrote:

> 15.10.2010 9:30, Alex Peshkoff wrote:
>> On 10/15/10 00:56, Dimitry Sibiryakov wrote:
>>> 14.10.2010 22:45, Jim Starkey wrote:
>>>> 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...
>>> isc_dsql_fetch() is supposed to get one row from result set. Result set is created by
>>> SUSPEND. No SUSPEND - nothing to fetch.
>>>
>> Dimitry, this is not correct logic. Fetch wants to pick up a message. As
>> the result of SP execution statement has output message. Why not let
>> fetch pick it up?
> What message fetch picks up when it returns 100?
>

Dimitry, did you check it yourself? Looks like not. It returns 0 first
time and 'request synchronization error' second time. The only problem I
see is that 100 is not returned on second call instead 'request
synchronization error'.