The CREATE TRIGGER statement is used to add triggers to the +database schema. Triggers are database operations (the trigger-action) +that are automatically performed when a specified database event (the +database-event) occurs.
+ +A trigger may be specified to fire whenever a DELETE, INSERT or UPDATE of a +particular database table occurs, or whenever an UPDATE of one or more +specified columns of a table are updated.
+ +At this time SQLite supports only FOR EACH ROW triggers, not FOR EACH +STATEMENT triggers. Hence explicitly specifying FOR EACH ROW is optional. FOR +EACH ROW implies that the SQL statements specified as trigger-steps +may be executed (depending on the WHEN clause) for each database row being +inserted, updated or deleted by the statement causing the trigger to fire.
+ +Both the WHEN clause and the trigger-steps may access elements of +the row being inserted, deleted or updated using references of the form +"NEW.column-name" and "OLD.column-name", where +column-name is the name of a column from the table that the trigger +is associated with. OLD and NEW references may only be used in triggers on +trigger-events for which they are relevant, as follows:
+ +| INSERT | +NEW references are valid | +
| UPDATE | +NEW and OLD references are valid | +
| DELETE | +OLD references are valid | +
If a WHEN clause is supplied, the SQL statements specified as trigger-steps are only executed for rows for which the WHEN clause is true. If no WHEN clause is supplied, the SQL statements are executed for all rows.
+ +The specified trigger-time determines when the trigger-steps +will be executed relative to the insertion, modification or removal of the +associated row.
+ +An ON CONFLICT clause may be specified as part of an UPDATE or INSERT +trigger-step. However if an ON CONFLICT clause is specified as part of +the statement causing the trigger to fire, then this conflict handling +policy is used instead.
+ +Triggers are automatically dropped when the table that they are +associated with is dropped.
+ +Triggers may be created on views, as well as ordinary tables. If one or +more INSERT, DELETE or UPDATE triggers are defined on a view, then it is not +an error to execute an INSERT, DELETE or UPDATE statement on the view, +respectively. Thereafter, executing an INSERT, DELETE or UPDATE on the view +causes the associated triggers to fire. The real tables underlying the view +are not modified (except possibly explicitly, by a trigger program).
+ +Example:
+ +Assuming that customer records are stored in the "customers" table, and +that order records are stored in the "orders" table, the following trigger +ensures that all associated orders are redirected when a customer changes +his or her address:
+} +Example { +CREATE TRIGGER update_customer_address UPDATE OF address ON customers + BEGIN + UPDATE orders SET address = new.address WHERE customer_name = old.name; + END; +} +puts { +With this trigger installed, executing the statement:
+} +Example { +UPDATE customers SET address = '1 Main St.' WHERE name = 'Jack Jones'; +} +puts { +causes the following to be automatically executed:
+} +Example { +UPDATE orders SET address = '1 Main St.' WHERE customer_name = 'Jack Jones'; +} Section {CREATE VIEW} {createview} @@ -398,6 +510,15 @@ Syntax {sql-command} { DROP TABLEUsed to drop a trigger from the database schema. Note that triggers + are automatically dropped when the associated table is dropped.
+} + puts {The DROP TABLE statement consists of the keywords "DROP TABLE" followed by the name of the table. The table named is completely removed from @@ -1091,129 +1212,6 @@ the database backend and VACUUM has become a no-op.
} -Section {CREATE TRIGGER} createtrigger - -Syntax {sql-statement} { -CREATE TRIGGERThe CREATE TRIGGER statement is used to add triggers to the -database schema. Triggers are database operations (the trigger-action) -that are automatically performed when a specified database event (the -database-event) occurs.
- -A trigger may be specified to fire whenever a DELETE, INSERT or UPDATE of a -particular database table occurs, or whenever an UPDATE of one or more -specified columns of a table are updated.
- -At this time SQLite supports only FOR EACH ROW triggers, not FOR EACH -STATEMENT triggers. Hence explicitly specifying FOR EACH ROW is optional. FOR -EACH ROW implies that the SQL statements specified as trigger-steps -may be executed (depending on the WHEN clause) for each database row being -inserted, updated or deleted by the statement causing the trigger to fire.
- -Both the WHEN clause and the trigger-steps may access elements of -the row being inserted, deleted or updated using references of the form -"NEW.column-name" and "OLD.column-name", where -column-name is the name of a column from the table that the trigger -is associated with. OLD and NEW references may only be used in triggers on -trigger-events for which they are relevant, as follows:
- -| INSERT | -NEW references are valid | -
| UPDATE | -NEW and OLD references are valid | -
| DELETE | -OLD references are valid | -
If a WHEN clause is supplied, the SQL statements specified as trigger-steps are only executed for rows for which the WHEN clause is true. If no WHEN clause is supplied, the SQL statements are executed for all rows.
- -The specified trigger-time determines when the trigger-steps -will be executed relative to the insertion, modification or removal of the -associated row.
- -An ON CONFLICT clause may be specified as part of an UPDATE or INSERT -trigger-step. However if an ON CONFLICT clause is specified as part of -the statement causing the trigger to fire, then this conflict handling -policy is used instead.
- -Triggers are automatically dropped when the table that they are -associated with is dropped.
- -Triggers may be created on views, as well as ordinary tables. If one or -more INSERT, DELETE or UPDATE triggers are defined on a view, then it is not -an error to execute an INSERT, DELETE or UPDATE statement on the view, -respectively. Thereafter, executing an INSERT, DELETE or UPDATE on the view -causes the associated triggers to fire. The real tables underlying the view -are not modified (except possibly explicitly, by a trigger program).
- -Example:
- -Assuming that customer records are stored in the "customers" table, and -that order records are stored in the "orders" table, the following trigger -ensures that all associated orders are redirected when a customer changes -his or her address:
-} -Example { -CREATE TRIGGER update_customer_address UPDATE OF address ON customers - BEGIN - UPDATE orders SET address = new.address WHERE customer_name = old.name; - END; -} -puts { -With this trigger installed, executing the statement:
-} -Example { -UPDATE customers SET address = '1 Main St.' WHERE name = 'Jack Jones'; -} -puts { -causes the following to be automatically executed:
-} -Example { -UPDATE orders SET address = '1 Main St.' WHERE customer_name = 'Jack Jones'; -} - -Section {DROP TRIGGER} droptrigger -Syntax {sql-statement} { -DROP TRIGGERUsed to drop a trigger from the database schema. Note that triggers - are automatically dropped when the associated table is dropped.
-} - puts {