10.06.2015 23:28, Claudio Valderrama C. wrote: > > I would like to be able to know that I'm dealing with MERGE or any other > statement that can lead to an update and/or insert. Adding > inserts+updates+deletes is not a problem (indeed, it's simpler code), but > it's a departure of the traditional logic. The current code provides the > result of the direct action of the statement. See this contrived example: > > create table master(a int primary key); > create table detail(b int primary key, master_a int not null references > master(a)); > insert into master values(0); > insert into master values(1); > insert into master values(2); > commit; > insert into detail values(10, 0); > insert into detail values(11, 1); > insert into detail values(12, 2); > commit; > set term ^; > create trigger tr_mod for master before update as begin > if (new.a != old.a) then > delete from detail where master_a = old.a; > end ^ > set term ;^ > update master set a = -1 where a = 0; > ^Z > > With the old logic, the result is one. With the new logic, the result is two > becaise we get the direct and indirect effects.
I doubt the new logic would return two. These counters are per-request and trigger is a separate request, so its changes shouldn't be counted for the parent request. > DSQL's get_request_info() retrieves not only the changes but the selected > records, too so we still need to filter out those. Sure, the idea was to sum up only I/U/D counters. > Has anybody thought what will we reported in the extreme event of more than > 2^32 updated or deleted records? The counters are going to overflow because > they are ULONG in the engine. What a cruel world ;-) Dmitry ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
