drsql.org
How to Write a DML Trigger
Louis Davidsondrsql.org
drsql.org
2
Agenda
• Introduction• Trigger Coding Review• Designing a Trigger Solution• Summary
drsql.org
Attention: There Is Homework(lots of it)
• I can’t teach you everything about DML triggers in 1 hour• There is a plethora of code the
comes with the download• It will get you started, but is
only just the tip of the iceberg
drsql.org
INTRODUCTIONA basic introduction to trigger concepts
drsql.org
5
What are DML Triggers?
• Coded modules that are very similar to stored procedures–Cannot be called directly–“Triggered” by an INSERT, UPDATE, or DELETE–With “special” tables to access event data
• Triggers existed in Microsoft SQL Server 1.0 (far before check constraints!)
drsql.org
6
DML Trigger Execution• Execute once per DML statement– Access the current state using INSERTED virtual object, removed rows via DELETED (Updates via both)– Work very well on limited cardinality, OLTP-esque types of modifications
• Should not seen and not heard unless they find something wrong– Don’t return results from triggers
• 2005-Later has “disallow results from triggers” server configuration• Ability to do so will be removed in an upcoming SQL Server version
– Caveat: returning results can be effective for debugging• Execute as part of the operation statement/transaction – ROLLBACK in the trigger will stop the operation (and anything else that is part of the current
transaction)– RAISERROR/THROW in trigger will make the transaction non-commitable
• Can use EXECUTE AS to elevate the permissions of the trigger code similar to stored procedures– Only in extreme circumstances!
drsql.org
7
DML Triggers – Two types• INSTEAD OF – When an INSERT, UPDATE or DELETE occurs, instead of the
typical code executed, the trigger executes instead. You have to code the effective INSERT, UPDATE or DELETE .– They are the first thing executed–Can be applied to view objects
• AFTER – When an INSERT, UPDATE or DELETE occurs, the typical operation occurs, and then the coded object executes after everything else.
• The use cases for each are different, which we will cover in a bit more detail later when we discuss designing a trigger solution
drsql.org
8
Multiple Triggers
• INSTEAD OF - Each table can have only 1 for each of the operations (Maximum of 3, for INSERT, UPDATE, DELETE)• AFTER–You can have “any” number of after triggers–You can only control the first and last trigger for an operation using
sp_settriggerorder
• Caution: More triggers is not necessarily more better
drsql.org
TRIGGER CODING TEMPLATE OVERVIEW
The framework to start a trigger with…
drsql.org
This session is not entitled:
How to Write DML Triggers To Implement all of your Data
Integrity Needsfor a reason…
drsql.org
11
Triggers are…
• Harder to get right than normal DDL solutions• Slower to operate than normal DDL solutions• Harder to support than normal DDL solutions
• Sometimes all we have to work with and then very very useful–Because what do customers care about?
drsql.org
12
Top Issues with Database Implementations
• #2 - Tie –Performance –Usability
• #1 Data Quality
• Anything we can do to protect the quality of the data worth the effort (and COST)• Every tool we have in SQL Server for data integrity has at least
some use
drsql.org
TRIGGER CODING REVIEWWhat makes triggers different from stored procedures
drsql.org
17
Core Trigger Validation Patterns• Negative – Look for any bad row
IF EXISTS ( SELECT * FROM INSERTED WHERE DataIsBad = 1) THROW 50000, N'bad data exists',1;
• Positive – Count that all modified rows are correct DECLARE @rowcount1 = ( SELECT count(*) FROM INSERTED WHERE DataIsBad IS NULL…) DECLARE @rowcount2 = ( SELECT count(*) FROM INSERTED WHERE DataIsBad = 0) IF @rowsAffected <> @rowcount1 + @rowcount2 THROW 50000, N'try again!',1;
– Typical use case will include an INNER JOIN to INSERTED
drsql.org
18
Core Trigger Modifications• Basically just executing a DML statement
• Cascading operationsDELETE TableName --likely other than the triggered oneFROM Schema.TablenameWHERE EXISTS (SELECT *
FROM DELETED WHERE DELETED.Key = TableName.Key)
• Instead of Trigger ModificationsINSERT INTO TableName (Key, Column1, RowLastModifiedTime)SELECT Key, UPPER(Column1), SYSDATETIME()FROM INSERTED
drsql.org
19
Core Trigger Modifications• AuditingINSERT INTO TableName_AUDIT (Operation, Key,Column1, RowLastModifiedTime, AuditTime)SELECT 'UPDATE',Key, Column1, RowLastModifiedTime, SYSDATETIME()FROM DELETED
• Error handling is managed by the TRY…CATCH block around all of the modification (and validation code)
drsql.org
20
Trigger Nesting/Recursion• When you execute a DML statement in a trigger, by default (and the most typical setting)– The trigger will nest (INSERT trigger on table A updates a row in table A and inserts a row into
table B would cause an update trigger on table A and an INSERT trigger on table B to fire if they existed)
– The trigger will not recurse (INSERT trigger on table A inserts a row into table A will not cause the trigger to refire)
• Two settings affect these conditions (with the default values)– exec sp_configure 'nested triggers',1;– alter database <DatabaseName>
set recursive_triggers off;
• There is a demo of changing this behavior in the downloads. These settings are dangerous because they can change behavior without changing code!
drsql.org
21
Determining Columns Modified
• Use the UPDATE function– IF UPDATE(<columnName>) --Means the column was referenced in the
statement• Example:
UPDATE table1SET column1 = column1 --,column2 = column2–UPDATE(column1) -> TRUE (even though no change)–UPDATE (column2) -> FALSE
drsql.org
22
Trigger Coding Basic Demo Setup
• Understanding multi-row operations• Error Handling
drsql.org
TRIGGER CODINGBASICS (DEMO)
Demonstrating the essential trigger coding techniques…
drsql.org
DESIGNING A TRIGGER
Making sure you understand what needs to be handled by the trigger before you start coding.
drsql.org
25
Designing a Trigger
• When using constraints, there will always be a single object needed to do the entire job–Check Constraint–Foreign Key
• When building a trigger, you have to cover:–All tables that are involved with the process–All operations that might be involved• INSERT• UPDATE• DELETE
drsql.org
26
Choosing the type of trigger to use – AFTER
• Typically used for validation and non-destructive cascading operations• Allow you to check the effects of the DML statement–You can see the state of database after the operation
• Examples–Audit Trails that work on any edition of SQL Server– Inter-row/Inter-table data validations, such as foreign keys/range
overlapping, where constraints will not work–Summary data (where heavily tested and determined to be necessary)
drsql.org
27
Choosing the type of trigger to use – INSTEAD OF
• Typically used to change the operation in some manner, either lightly or dramatically• Also for cascade operations to avoid RI errors, like a cascade delete• Examples–Overriding format of data (formatting input, overriding user input, such as a
date and time)– Ignoring/logging for review “bad” data (high speed data entry, instrument
data)–Making multi-table views updatable using simple T-SQL–Turning a physical delete into a logical delete – …set deletedFlag = 1
drsql.org
28
Scenario Introduction
Let’s look at 3 basic scenarios1. Maintaining a row inserted and updated time on a row2. Preventing a negative balance3. Managing an audit trail
Note: in all of these cases, the requirement we will use will be that the logic cannot be overridden.
drsql.org
29
Maintaining a row inserted and updated time on a row
Table Involved
Table1 (Table1Key, RowCreatedTime, RowLastModifyTime)
Row Inserted
Row Updated
Row Deleted
Type of triggers: INSTEAD OF
drsql.org
30
Preventing a Negative BalanceTables Involved
Parent Table(ParentId (not changeable), ChildValueSum (not stored))
Child Table (ChildId, ParentId FK, Value)
Row Inserted Row Inserted
Row Updated Row Updated
Row Deleted Row Deleted
Type of triggers: AFTER
drsql.org
31
Managing an audit trailTable Involved
Table1 (Table1Key, RowCreatedTime, RowLastModifyTime)
Row Inserted
Row Updated
Row Deleted
Type of triggers: AFTER
drsql.org
PRE-DEMO SUMMARY, IN CASE TIME IS NIGHTriggers are equal parts friend and foe
drsql.org
TRIGGER DESIGN AND CODING SCENARIOS
Code review …
drsql.org
ADVANCED TOPICSSettings and metadata to fully understand trigger operation
Note: This section may not be achievable in a 90 minute session but will be available to download with examples
drsql.org
35
Advanced Topics To Cover (Demos)• Getting trigger metadata - queries• Multiple triggers of the same type on the same table and ordering• Trigger Nesting/Recursion• System Settings - can change trigger execution without changing code– sp_serveroption— nested triggers (default ON)– Determines if a DML statement from
one trigger causes other DML triggers to be executed– database option—RECURSIVE_TRIGGERS (default OFF)– Determines if an update on the
table where the trigger fired causes the same triggers to fire again– sp_serveroption–disallow results from triggers (default OFF): Turn this setting on will
ensure that any trigger that tries to return data to the client will get an error – sp_serveroption-server trigger recursion (default ON) – Determines if DDL in a server DDL
trigger causes it to fire again
drsql.org
ADVANCED TOPICS (DEMO)
Coded examples showing some advanced trigger concerns
drsql.org
37
Conclusion
• Triggers are no one’s favorite tool• They are sneaky and tend to complicate support, testing,
maintenance, etc• But that sneakiness makes them powerful
• Use sparingly, whenever necessary
drsql.org
38
Questions? Contact info..
• Louis Davidson - [email protected]• Website – http://drsql.org Get slides here• Twitter – http://twitter.com/drsql
• SQL Blog http://sqlblog.com/blogs/louis_davidson
• Simple Talk Blog – What Counts for a DBAhttp://www.simple-talk.com/community/blogs/drsql/default.aspx