Triggers 7/11/2019 See scm-intranet

Objective To develop an understanding of event based triggers. To explore the role of triggers in the construction of transactions. 7/11/2019 See scm-intranet

Triggers A trigger is a routine which is associated with a database object; typically a table.   A trigger is executed 'fired' when some condition becomes true. So, a trigger is implicitly executed rather than called like a function or procedure. 7/11/2019 See scm-intranet

Triggers have the property of atomicity like transactions- wholly successful or not. 7/11/2019 See scm-intranet

Contains any new rows for a table. Created by insert actions. At the point a trigger intercepts an operation two temporary tables exist.  Inserted table  Contains any new rows for a table. Created by insert actions.  Deleted table  Contains rows for removal. Created by delete actions  Update actions create both an inserted table and deleted table. New rows in inserted, and old rows in deleted.  Tables only exist for scope of the event and are removed when all triggers for that event are complete and data committed. 7/11/2019 See scm-intranet

So, conditions (If’s) must take this into account. When programming a trigger the data being inserted, deleted or updated must be assumed to be in the table until transaction is complete (committed). So, conditions (If’s) must take this into account. E.g. if testing that data to be inserted does not conflict with other data the trigger must assume that the new data is already inserted. So, any query conditions in the trigger will be tested against the new data as well as the existing data. Trigger can terminate and rollback the transaction, thereby removing the inserted data if an error is detected Transaction not committed until all triggers complete. 7/11/2019 See scm-intranet

SQL*Server Triggers A type of stored procedure. Executed automatically when a table updated.  Cannot pass values in and out of triggers. Create trigger trigger_name On table_name For {insert, delete, update} As sql_statements;  Triggers removed using- drop trigger <name> 7/11/2019 See scm-intranet

Dropping a table removes all associated triggers- this means that a trigger definition separate from the table is needed so that they can be easily re-created and re-used (hence better to manage triggers using Query Analyser rather than Access 2000.) Triggers are a component of schemas. 7/11/2019 See scm-intranet

Example- to reject some invalid data @ designates a parameter. Create trigger tri_ins_sale On sales For insert, update As Select @ndayofmonth = datepart(day, I.ord_date)  {place the day as an integer from the column ord_date from table I in parameter} From sales s, inserted I Where s.stor_id=I.stor_id And s.ord_num=I.ord_num And s.title_id=I.title_id If @ndayofmonth>15 Begin {Test the day number and reject transaction if appropriate} Rollback tran {Rolls back to last BEGIN TRANS or default equivalent} Raiseerror ('orders must be placed before 15th of month, 16, 10) End Go   Detailed syntax in Transact*SQL Help under Triggers. 7/11/2019 See scm-intranet

Cascading Referential Actions using Triggers This is only relevant to SQL*Server 7. (Referential actions should be declared using foreign key declarations in SQL*Server 2000) Referential Integrity  SQL*Server 7 does not support cascade as a referential operation. This can be dealt with using a trigger so long as no referential constraints (foreign keys) are declared in the database schema. This is because violation of the declared constraint is detected before the trigger fires. 7/11/2019 See scm-intranet

Cascades e.g. to cascade update on a customer table to a related order table. Order contains the foreign key customerid (for the primary key of customer). This cascades an update to the customer table into the order table i.e. a change to a customerid in the customer table results in changes to the associated customerid's in the order table. 7/11/2019 See scm-intranet

create trigger update_customer on customer for update declare @cidold nchar(5), @cidnew nchar(5) select  @cidold =customerid from deleted select  @cidnew =customerid from inserted if  exists(select * from orders where customerid=@cidold) update orders set customerid=@cidnew where customerid=@cidold Syntax and method the same for cascaded deletes. 7/11/2019 See scm-intranet

Summary SQL based routines can be executed implicitly as a result of an action or some condition becoming true (‘triggered’) Used to protect the integrity of the database or to add value to database operations by automating complex activities This can produce a cascade of database operations 7/11/2019 See scm-intranet