On 06/09/2015 07:13 AM, Claudio Valderrama C. wrote: > Hello, I want to hear opinions on this: > > currently, MERGE is always reported as this value of statement type: > #define isc_info_sql_stmt_insert 2 > > It seems to be always an insert statement for the engine. So far so good. > Now, please look at isql's process_record_count(): > because the input param statement_type is 2, isql will pick > count_type = isc_info_req_insert_count; (value 14) > > Now isql calls the information routine with isc_info_sql_records and starts > looping. It's trying to match isc_info_req_insert_count to any of the > possible answers from the engine. However, when the engine executes > something like this > MERGE ... WHEN MATCHED THEN UPDATE SET... > the answer comes with the tag > #define isc_info_req_update_count 15 > whereas the tag isc_info_req_insert_count is followed by zero. Correct > behavior from the engine's POV, but it makes isql to miss the result of any > UPDATE clause in a MERGE statement. > > Ideas? > - Have the server inform the client in some way this is a MERGE statement > such that isql can pick insert and update numbers, sum them and return them > as the total number of records affected? > - Throw away the logic isql has always used?
May be not throw but slightly extend? In non-merge INSERT update count should always be 0. Can we always take into an account non-zero update count for insert-like-reported statements? ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
