Subject | Re: [Firebird-Architect] Batch/Block operations |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2005-02-22T05:55:07Z |
On 21 Feb 2005 at 23:25, Vlad Horsun wrote:
no. Such applications know for sure statement type and don't care
about plan.
Setting name of cursor is completely pointless without following
'...WHERE CURRENT OF...' statements.
Nevertheless following suggestions are very good. Especially
eliminating of isc_alloc_statement() call.
return?
--
SY, Dimitry Sibiryakov.
>Universal applications (connectivity drivers) - yes. Specialized -
>> The protocol reflects the API. Do you have any suggestions for
>> reducing the number of round trips?
>
> Very often appliactions repeat this steps
>
>isc_alloc_statement2
>isc_prepare
>isc_dsql_sql_info (isc_info_sql_stmt_type)
>isc_dsql_sql_info (isc_info_sql_get_plan)
>isc_dsql_execute2
>isc_dsql_set_cursor_name
>isc_dsql_sql_info (isc_info_sql_records)
>...
no. Such applications know for sure statement type and don't care
about plan.
Setting name of cursor is completely pointless without following
'...WHERE CURRENT OF...' statements.
Nevertheless following suggestions are very good. Especially
eliminating of isc_alloc_statement() call.
> First step may be to merge isc_xxx_info calls into correspondingNever used isc_transaction_info. What _useful_ information can it
> xxx calls,
>for example :
>
>[isc_alloc_statement2 + ] isc_prepare + isc_dsql_sql_info
>
>isc_dsql_execute2 + isc_dsql_sql_info [+ isc_dsql_set_cursor_name]
>
>isc_start_transaction + isc_transaction_info
return?
--
SY, Dimitry Sibiryakov.