Subject | Re: [Firebird-Architect] Re: RFC: Please unify stored procedure execution |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2004-12-21T12:47:06Z |
On 21 Dec 2004 at 12:20, Roman Rokytskyy wrote:
application call EXECUTE PROCEDURE with isc_dsql_execute() or
isc_dsql_execute2() and then do not close cursor with
isc_dsql_free_statement(DSQL_close) because there is no cursor.
After proposed changes the statement may return cursor or not. So,
if the application try to close the cursor, it may get 'no cursor'
error. If the application don't close the cursor, it'll be opened
till freing of statement handle that may be a quite long time.
And what if application call EXECUTE PROCEDURE with
isc_dsql_exec_immed2()? Return only the first row from cursor or
'Multiple records in singleton select' error (as it is done now).
--
SY, Dimitry Sibiryakov.
>> And, yes, if this does not violate standard and commonI'm afraid it could cause resource leaks. I.e. currently an
>> behavior, you can RFC to allow execute procedure to return more than
>> "1 row", if it can.
>
>So, what do you (all) think about extending EXECUTE PROCEDURE?
application call EXECUTE PROCEDURE with isc_dsql_execute() or
isc_dsql_execute2() and then do not close cursor with
isc_dsql_free_statement(DSQL_close) because there is no cursor.
After proposed changes the statement may return cursor or not. So,
if the application try to close the cursor, it may get 'no cursor'
error. If the application don't close the cursor, it'll be opened
till freing of statement handle that may be a quite long time.
And what if application call EXECUTE PROCEDURE with
isc_dsql_exec_immed2()? Return only the first row from cursor or
'Multiple records in singleton select' error (as it is done now).
--
SY, Dimitry Sibiryakov.