Peter Aronson <pbaronson@...> writes: > create trigger if not exists iupdate_up before update on iupdate > begin > select raise(fail,'halt in processing requested') where old.c1 = 7; > end;
Yes, thank you, this raise(fail, ...) does, indeed, aborts the update loop without rolling back all previous updates. The timing of this approach is much worse than of rowid range: 50% slower on 100,000 rows and 6 times slower on 1 mln rows. This is because it has to loop through entire table again and again. But this will also be the case if interrupt with commit would have been possible, which was my original desire. Another question is whether it is capable of preventing timeouts. At the first glance it cannot since the maximum time of a single query on 1 mln rows is 4.5 seconds (this is simply the time of looping through these rows plus some overhead of the trigger). These 4.5 seconds are dangearously close to timeout of 5 seconds. But, in reality the table is not locked for the duration of entire update query. It appears that first trigger is called about 3 seconds after the update query started and the last - about 1 second later. And the table is locked for less than 1 second. but can this be relied upon? May be this will depend on actual positions of rows with C1 is NULL? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
