Re: [IBPP-DISCUSS] Problem with EXECUTE PROCEDURE and Fetch()

[Fulvio S. <ma...@fs...>]

Thank you for your answer, calling Type() solved my problem.

BTW, it might me a good idea to update the documentation of the Fetch() 
method with these info.

At the moment the web page says:
"After a successul Execute() or CursorExecute(), use Fetch() to retrieve 
rows of the result set, one at a time. You have to call Fetch() to 
access your result set (when you expect one) even though your result set 
is known to consist of a single row."

That gave me the false impression that I must call Fetch() even when 
executing a stored procedure that returns a single value.

Fulvio Senore


Il 20/05/2012 22.59, Olivier Mascia ha scritto:
> Hello,
>
> Le 19 mai 2012 à 23:30, Fulvio Senore a écrit :
>
>> I am executing sql statements using the Execute() method if the
>> statement object.
>>
>> Something like:
>>
>>
>> m_st = StatementFactory( GetIBPPDatabase(), m_tr );
>> m_st->Execute( sql );
>>
>>
>> I have just learned the hard way that if I execute something like a
>> SELECT statement I must call Fetch() to get the first result row, but if
>> I execute an EXECUTE PROCEDURE statement to execute a stored procedure
>> that returns a single value I must not call Fetch() or I get an exception.
>
> Indeed, correct. As designed per InterBase (and possibly dating back further).
>
>> The problem is that I am executing sql statements from some generic code
>> so I don't know if the statement will need a call to Fetch() or not.
>
> Then you have to get to know.  :)
>
>> Is it calling Type() to get the STT type of the executed statement a
>> good idea?
>
> It merely exists for such situations.
>
>> Is it safe to assume that if the type is stExecProcedure then
>> I must not call Fetch(), or will a selectable stored procedure return
>> the same type?
>
> Yes a selectable stored procedure will be reported by the engine as a select statement.
>
>> Is there another way to know if the statement that I have just executed
>> will need a call to Fetch() or not?
>
> I don't think so.  Only select-like statements may use fetch when the result set is non-empty.  (A SELECT returning NO row, would throw() on Fetch()).
>
> Calling Type() (which is known as soon as Prepare() is done, so even before Execute() if you split those) will cost you nothing, as this is an information returned by the engine at Prepare() time.
>
> Sincerely,