Hello Jason,

> Yes, it would. That's why I petitioned to have them add an implicit SUSPEND
> when none are included and there are columns for output.
> See: http://tracker.firebirdsql.org/browse/CORE-3695
>
> With FB 2.5 you would only be able to use them with any connectivity library
> if you modify it to have a call to SUSPEND in the body.
> See: http://tracker.firebirdsql.org/browse/CORE-3680
>
> Look closely at the dialog between Adriano and Vlad.
>
> Vlad answered:
> "IIRC, initial implementation was changed at v2.5 to be more consistent with
> more strict rules of usage of SUSPEND in PSQL"
>
> There appears to have been a deliberate departure from the legacy ability to
> omit the SUSPEND and yet get a singleton output result.
>
> Hope this helps clear up the murky waters.
>
> Perhaps you will consider pushing for the implementation of my request so
> that legacy applications will not be broken. I see nothing gained by forcing
> people to plunk in a SUSPEND in all their singleton execute block and stored
> procedure statements.

Thanks for the clarification, although I'm not satisfied. ;-) Just to be
sure, I'm not talking about an example Vlad has given in CORE-3680:

<quote>

CREATE PROCEDURE P1
RETURNS (I INT)
AS
BEGIN
I = 1;
END


and try to excecute SELECT * FROM P1 using isc_dsql_execute2().
You will get the same error.
This is exact analoug of EXECUTE BLOCK you are complaining about.

</quote>


I'm not talking about executing the procedure as SELECT * FROM <SP> at
the client side but rather some kind of EXECUTE PROCEDURE ...
RETURNING_VALUES ... equivalent? I don't know the IBO internals, e.g.
what client API call TIB_StoredProc.ExecProc is issuing.

Adding SUSPEND to a SP which is then used as EXECUTE PROCEDURE ... has
been treated as devil already in the old InterBase days. I'm just
seeking for the reason why the most recent IBO version behaves
differently in that area with the same Firebird engine version.

Or possibly I simply don't understand the problem in its full potential. ;-)

Thanks,
Thomas

> Thanks,
> Jason
>
> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On Behalf
> Of Thomas Steinmaurer
> Sent: 09 January 2012 01:31 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] 4.9.14b32 - Problem with executable SP and output
> parameters
>
> Hello Jason,
>
>> As I understand it, with newer versions of Firebird you can't get a record
>> out of it without a call to SUSPEND regardless of what API call you use.
>
> Wouldn't that break a LOT OF legacy applications in respect to the usage
> of executable SPs, as we have been told over the last 10 years not to
> use SUSPEND in executable SPs. ;-)
>
> Back to IBO: How would you use executable SPs in Firebird 2.5 with IBO?
>
>
> Thanks,
> Thomas
>
>
>
>> TIB_DSQL won't do anything better than the TIB_StoredProc.
>>
>> Jason
>>
>> -----Original Message-----
>> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On
> Behalf
>> Of Thomas Steinmaurer
>> Sent: 09 January 2012 01:11 AM
>> To: IBObjects@yahoogroups.com
>> Subject: Re: [IBO] 4.9.14b32 - Problem with executable SP and output
>> parameters
>>
>> Hi Jason,
>>
>>> The reason it will have appeared to work is because there was also a time
>>> when there was a bug in the API call and so in order to work around that
>> bug
>>> I didn't use the isc_dsql_execute2() API call. I actually used the
>>> isc_dsql_execute() API call which required me to open a cursor, fetch one
>>> record, and then close the cursor.
>>
>> Ok, then how do I execute an executable stored procedure without a
>> SUSPEND in the body and returning output parameter values? Obviously I
>> can't do that anymore with a TIB_StoredProc and the ExecProc call.
>>
>> With a TIB_DSQL?
>>
>> Thanks,
>> Thomas
>>
>>> So, the waters are considerably murky.
>>>
>>> Jason
>>>
>>> -----Original Message-----
>>> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On
>> Behalf
>>> Of Thomas Steinmaurer
>>> Sent: 09 January 2012 12:48 AM
>>> To: IBObjects@yahoogroups.com
>>> Subject: Re: [IBO] 4.9.14b32 - Problem with executable SP and output
>>> parameters
>>>
>>> Hello Jason,
>>>
>>>> The change took place in Firebird, not IBO.
>>>
>>> Hmm. I was trying an older IB LogManager version with Firebird 2.5 where
>>> it worked. Recompiled IBLM with the most recent IBO version against
>>> Firebird 2.5 shows the problem, so it isn't a pure Firebird engine
>> problem.
>>>
>>> Regards,
>>> Thomas
>
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more ! Yahoo! Groups Links
>
>
>