Dan Kennedy-4 wrote:
>
> Sounds like it.
>
> Calling sqlite3_prepare_v2() generates the VM code for all
> triggers that could possibly be invoked by your statement.
> All it considers when determining which triggers might be
> needed is the type of statement (UPDATE, DELETE, INSERT) and
> for UPDATES, the columns updated.
>
Thanks Dan. However, I think it's more correct to say that it generates the
VM code for all triggers that could possibly be invoked by the statement
*and any related triggers*.
It appears to expand the pool of possible triggers on the fly based upon the
content of each trigger that it's queuing up. For example, this trigger:
CREATE TRIGGER fki_Tasks_PerComp_Range AFTER INSERT ON Tasks FOR EACH ROW
WHEN NEW.PerComp IS NULL
BEGIN
UPDATE Tasks SET PerComp = 0 WHERE RowID = NEW.RowID;
END;
Is causing all my triggers related to an update on the Tasks table to be
queued up when I execute an INSERT on Tasks *with* PerComp = 0 (not null).
I guess I was expecting a short circuit evaluation on the FOR EACH ROW WHEN
conditions.
--
View this message in context:
http://old.nabble.com/Trouble-with-TRIGGERS-tp30228089p30232856.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
