Triggers. o o. o o. We will see that triggers are mainly used in two areas:

Transcription

1

2 Triggers As we apprach the cnclusin f this bk, we cme t an imprtant tpic in the specialized stred prcedure arena - triggers. Triggers are best used fr enfrcing business rules as well as perfrming validatin r data mdificatins, when ther methds are nt sufficient. We will see that triggers are mainly used in tw areas: Creating audit recrds and reflecting changes t crucial business tables Validating f changes against a set f business rules cded in T-SQL In this chapter, we will cver: What a trigger is and why it exists Perfrmance cnsideratins Hw t create a trigger and its different types Transactins and rllbacks within triggers Recursive triggers Gd and bad prgramming practices T. Bain et al., SQL Server 2000 Stred Prcedures Handbk Apress 2003

3 Chapter 7: Triggers What is a Trigger? A trigger is a specialized stred prcedure which fires autmatically when an alteratin ccurs t an underlying table due t an actin like deleting, inserting, r updating f a rw, r a batch f rws, within the single table that the stred prcedure is linked with, r ptentially multiple tables if the trigger is linked t a view. T clarify the statement f 'batch f rws' - if we have an UPDATE statement that mdifies several rws, fr example, then the trigger will nt fire fr each rw updated, but nly nce when the batch cmpletes. If we needed t fire the trigger fr each rw being updated, then we wuld need t cnstruct sme srt f lp prcessing within ur T-SQL t d this. Triggers can be assigned t tables r views. Hwever, althugh there are tw types f triggers, INSTEAD OF and AFTER, as we will see later in the Types f Triggers sectin, nly ne type f trigger can be assigned t views. Briefly, an INSTEAD OF trigger is the ne that is usually assciated with a view, and runs n an UPDATE actin placed n that view. An AFTER trigger fires after a mdificatin actin has ccurred. It is pssible t have mre than ne trigger firing fr the same actin, if they are AFTER triggers. S it is quite pssible and perfectly valid fr tw r mre separate triggers t fire n the same table mdificatin actin. This will allw separate prcessing t take place, rather than having different underlying functinalities in the same prcedure. It is als pssible t define the rder in which triggers will fire. Bth these areas are cvered in detail, in the Types f Triggers sectin. Frm a perfrmance viewpint, the fewer the triggers, the better, as we will invke less prcesses. Therefre, d nt think that having ne trigger per actin t make things mdular will nt incur perfrmance degradatin. A trigger's main verhead is referencing either tw specialist tables that exist in triggers - deleted and inserted r ther tables fr business rules. Mdularizing triggers t make the whle prcess easier t understand will incur multiple references t these tables, and hence a greater verhead. It is nt pssible t create a trigger t fire when a data mdificatin ccurs in tw r mre tables. A trigger can be assciated nly with a single table. Care has t be taken in areas such as DTS r Hep, when lading data int tables, as we may wish t switch ff the firing f the triggers. DTS (Data Transfrmatin Services) is a tl within SQL Server t allw bulk lading f data, data manipulatin, and many ther useful prcesses surrunding data. BCP is the predecessr f DTS, and is a simple prmpt-based utility fr bulk lading frm a surce t SQL Server. Drpping the trigger frm the database, r using the DISABLE TRIGGER ptin f the ALTER TABLE statement, may be needed in such cases. We can then cmplete the bulk lading and reapply the trigger. If the trigger remains in place, and we bulk lad a number f rws, then a trigger culd be fired nce fr each rw being placed int SQL Server, and hence it shuld remain nly if we need this. Fr example, lading 100,000 rws will slw dwn a nrmally fast prcess. If a trigger exists as part f auditing, then we may remve it. 198

4 What is a Trigger? Disabling the trigger is the preferred ptin; therwise, we will need t recreate the trigger nce it has been drpped.! Care must be taken t ensure that we perfrm the DROP r DISABLE nly when there are n ther tasks being perfrmed at that time. If we drp the trigger when a valid task is running, then we may crrupt the data, especially if the trigger is perfrming a business functin. Triggers shuld be drpped nly when they will nt be invked. One way t ensure this is t change the database Access prperty thrugh the Restrict Access clause, t a Single User in the Prperties page f the desired database, in the Enterprise Manager. G al) "ar... 1 T...-nlpl"..., p i Re:bic'tllCUlt r. r r ; R ~ RIICOVOIY Mdel: Sli... Is""" r ANSI NULL del'" r Rec.uw.reInggef, I" A u l Ie> _ ~ ' " I"T"",.-del_ r _d<e r_u.-... P' A t. k J a e d l ~ C I I. 4 t c 1 r U""""'dtdrl"'" ::J Later, in the Replicatin sectin, we will als lk at triggers in places where replicatin f a database is invlved. Triggers are nt designed fr returning any infrmatin. N parameters can be passed t them, and returning a rwset f infrmatin will cause lgistical prblems in the invking prcedure. Jf yu are cncerned that a rwset may be returned, then use the SET NOCOUNT statement at the start f the trigger t ensure that n rws are returned. 199

5 Chapter 7: Triggers Why use Triggers? Using triggers can greatly imprve data integrity. When an actin is perfrmed n data, it is pssible t check if the manipulatin f the data cncurs with the underlying business rules, and thus avid errneus entries in a table. Fr example: We might want t ship a free item t a client with the rder, if it ttals mre than $1000. A trigger will be built t check the rder ttal upn cmpletin f the rder, t see if an extra rder line needs t be inserted. In a banking scenari, when a request is made t withdraw cash frm a cash pint, the stred prcedure will create a recrd n the client's statement table fr the withdrawal, and the trigger will autmatically reduce the balance as required. The trigger may als be the pint at which a check is made n the client's balance t verify that there is enugh balance t allw the withdrawal. By having a trigger n the statement table, we are secure in the knwledge that any statement entry made, whether withdrawal r depsit, will be validated and prcessed in ne central place. Nte that we discuss nly data integrity here, and nt referential integrity. We may als wish t replicate changes in ne database int anther; a trigger n the table that is being updated will be ideal t place the changes frm the 'live' database t the 'audit' database. We use this scenari t create an audit n specific tables, but the audit is kept in a separate database. When we discuss building triggers, in the Creating and Using a Trigger sectin, we will see this scenari in actin. This is different frm replicatin, which we will discuss later in the Replicatin sectin. Anther use f trigger can be t carry ut an actin when a specific criterin has been met. One example f this is a case where an requesting mre items t be delivered is sent, r an rder fr prcessing culd be placed, when stck levels reach a preset level. Hwever, if we insert data int anther table frm within a trigger, we have t be careful that the table we insert int desn't have a trigger that will cause this first trigger t fire. It is pssible t cde triggers that result in an endless lp, as we can define a trigger n TableA, which inserts int TableB, and a trigger fr TableB, which updates TableA. This scenari will ultimately end in an errr being generated by SQL Server. The fllwing diagram will demnstrate this: 200

6 Perfrmance Figure 1 Prcess A updates Table A Table A 2 3 Trigger fires n Table A change. Updates Table B 5 Table B 4 Trigger fires n Table B change. Updates Table A 1. A stred prcedure, A, updates TableA. 2. This fires a trigger frm TableA. 3. The defined trigger n TableA updates TableB. 4. TableB has a trigger which fires. 5. This trigger frm TableB updates TableA. Perfrmance Remember that fr every trigger, since we execute mre cde than fr a simple insertin, keep trigger cde minimal. Triggers are als 'hidden' frm a develper, as it is nt immediately visible that a table has a trigger n it, unless the develper knws the system, r there is gd dcumentatin arund. They may create a new prcess that refreshes the data every night and may nt immediately realize this slws dwn the prcess. Fr example, if we have a number f recrds t lad frm a data repsitry, a stred prcedure r DTS prcess lads the data int the main table that has an audit trigger n it. This trigger mdifies the audit table with the ntified changes. The verall prcess will slw frm a straightfrward lad due t the trigger, the extra insertin, and any ther wrk SQL Server has t index n the audit table. We may try remving the trigger itself and then updating the audit table as a separate batch prcess later in the verall cycle, if pssible. 201

7 Chapter 7: Triggers Figure 2 Data Lad Stred prcedure t nly lad data T r i gr g~ fr audit table Deferred Updates and Direct Updates While mdifying rws in a table, SQL Server can emply any f the tw different methds - direct update r deferred update. As the name suggests, a direct update will mdify the table directly with the data that is already there. Once this is dne, the transactin lg is then created. Every mdificatin t a rw in the mdified table will then create a recrd f the rw in the transactin lg, and the altered clumn values f the underlying table will simply have their infrmatin verwritten in the transactin lg. In a deferred update, the rw t be mdified is placed int the transactin lg as a delete, and then an insertin with the mdificatins is placed in the transactin lg. The rw is then deleted frm the table, and then reinserted int the table with the new infrmatin, with the last tw actins taking the infrmatin frm the lg. This is bviusly slwer than the first methd as we have t re-read the data frm the transactin lg, as well as remving and inserting whle rws f data. As sn as we place a trigger n a table, we frce SQL Server t use the deferred update methd f table mdificatin. Therefre, althugh we may find that the cde within the trigger itself is very quick, we will degrade perfrmance f the data mdificatin by placing the trigger. Creating and using a trigger A trigger is created by a CREATE statement. The syntax fllws: CREATE TRIGGER name ON table [WITH ENCRYPTION) [FOR/AFTER/INSTEAD OF) [INSERT, UPDATE, DELETE) [NOT FOR REPLICATION) AS BEGIN END 202

8 Creating and using a trigger We will lk at the tw ptins fr the type f trigger, AFTER and INSTEAD OF, in the Types f Triggers sectin. When naming a trigger, it is best t fllw the naming standard f prefixing the name with tr_, fllwed by actins the trigger is fr, like ins fr insert, upd fr update, del fr delete, and lastly, the name f the table that the trigger is attached t. If we create mre than ne trigger fr a table, fr the same set f actins, which is pssible with AFTER triggers, then we will suffix each trigger with ther infrmatin t identify each ne. If we had a trigger n the rders table, which will fire n an INSERT nly, then it will be called tr_i_rders r tr_irders. Many peple prefer the first methd, as it makes the assciated trigger actin clearer. As a trigger fires n an actin (unlike prcedures, which are invked), it is bvius that it is nt pssible t pass in any parameters. All f the infrmatin fr a trigger has t cme frm table infrmatin. If we need t pass in sme srt f parameter infrmatin, then prir t executing the triggering actin, we need t create a temprary table that can then be referenced by the trigger. There are tw ccasins when a trigger will nt fire n a mdificatin actin: Triggers fire n lgged actins, such as an INSERT, when the actin is placed in the transactin lg. TRUNCATE TABLE statements are nn-lgged actins, which is ne reasn fr TRUNCATE TABLE being faster than a DELETE with n WHERE statement, as a TRUNCATE TABLE will nt fire any underlying triggers. The secnd ccasin is when we use WRITETEXT t write infrmatin t a TEXT data type clumn. This is als a nn-lgged actin, and therefre cannt fire a trigger. Cde within triggers needs t be shrt. Any trigger that fires n a table mdificatin will reside in the same transactin as the mdificatin actin that fired it. Therefre, the lnger a trigger takes t run, the lnger the lck n any rws r tables is held. It is pssible t reference any tables within the database in which the trigger resides, tables utside the cntaining database, r any temprary table created in the calling batch. Remember that every such actin will degrade perfrmance, and hence it is crucial t create ptimal T-SQL cde. We will lk at replicatin and triggers, but it will be useful t make the pint abut using the NOT FOR REPLICATION ptin in the trigger. If we cde ur trigger with this ptin, we are indicating that if the database is replicated, this trigger will nt fire when the update cming int the table is frm a replicatin actin.! When we set up replicatin within SQL Server, ~ can e autmatically transfer triggers frm the publisher t the subscriber database. If the publisher is marked NOT FOR REPLICATION, and placed in the subscriber. If the trigger des nt have this ptin, then the triggers will als be replicated withut the ptin, which may nt be what we want. 203

9 Chapter 7: Triggers Althugh nt a mandatry ptin, it is best t keep this in mind in case ur cmpany decides t replicate a prductin database t anther lcatin. We can encrypt a trigger fr security, as with stred prcedures, hence the WITH ENCRYPTION ptin in the syntax. The Cnceptual Tables within Triggers When a trigger fires, there are tw cnceptual tables available fr use t check data changes. Fr example, let's say we are updating a rw in TableA in sme database. SQL Server knws we have an update trigger n this table, s it takes an image f the rw befre the mdificatin takes place, then allws the mdificatin t ccur, and finally takes an image f the rw. This pre-mdificatin image is placed int a table called deleted, as we delete the values in the ld rw. The pst-mdificatin rw is placed int a table called inserted. Remember that these tables nly exist within a trigger. A deletin will have a rw in the deleted table and an insertin will have a rw in the inserted table, per rw mdified. We can demnstrate this in the fllwing trigger: CREATE TRIGGER tr_upd_orderscunt ON rders AFTER UPDATE AS BEGIN VARCHAR(20) = CAST (COUNT (*) as VARCHAR(lO» = 'Rws Updated ' RAISERROR(@Rc,l,l) END FROM deleted If we update the data with the fllwing, we will see that Rws Updated as well as the COUNT fr the UPDATE cmmand cmes t 5. UPDATE rders SET RequiredDate WHERE CustmerId RequiredDate 'VINET' The utput f the UPDATE is: Msg 50000, Level 1, State Rws Updated 5 (5 rw(s) affected) 204

10 Creating and using a trigger When wrking with multiple mdificatins, it is necessary t have a methd t match the rws in the deleted table with the rws in the inserted table. Nrmal practice will be t use the primary key, prviding that this gives unique rws, withut which we may need t alter ur underlying table. These cnceptual tables are held in memry, and hence are fast. If a trigger fires after a large number f rw mdificatins, it is nt pssible t index these tables t speed up the trigger. Triggers Fired n an Update When a trigger fires n an UPDATE r INSERT actin, it is pssible t find ut if a specific clumn value has been mdified. If the IF UPDATE clause is used, SQL Server will cmpare the values in that clumn frm the deleted table with thse in the inserted table, t determine if a mdificatin has taken place. If every clumn in the IF statement has been updated r inserted, then this will return a TRUE value, and the trigger will then drp in the relevant cde blck fr the decisin. This is faster than multiple IF... ELSE IF..., where we will need ne IF per clumn. Cmputed and TEXT data type clumns cannt be placed in the UPDATE test. There is anther similar functin called COLUMNS_UPDATED that returns a bitmask f the clumn number f every clumn that has als been mdified. A bitmask is simple binary psitining fr the clumns in a table. We can see the bitmask value against each clumn in the table: Clumn in table Bitmask value First 1 Secnd 2 Third 4 Furth 8 Fifth 16 Sixth 32 Seventh 64 Eighth 128 If we want t check if the secnd, fifth, and seventh clumns have been updated, then add 2, 16, and 64 (result is 82), and the SQL statement will be IF COLUMNS_UPDATED ( 82 ). It will nt matter if the ther clumns have als been updated, as this statement will nly cnsider the three clumns mentined. 205

11 Chapter 7: Triggers As we can see, we have mentined the first eight clumns nly. What if we want t check if the ninth clumn has been updated? The value will nt be 256 because we are ging frm ne byte t tw bytes, and COLUMNS_UPDATED () wrks n the bit settings f ne byte nly. Well, we can still d this, but we have t SUBSTRING that secnd byte frm COLUMNS_UPDATED ( ), and then use the POWER functin. Cde t test clumns 4, 7, 10, and 12 is as fllws: IF SUBSTRING(COLUMNS_UPDATED(),1,1) = POWER(2,4-1) + POWER(2.7-1) AND SUBSTRING(COLUMNS_UPDATED().2,1) = POWER( ) + POWER(2,12-8-1) This can be clarified as i 1 + 2H (as we want t test clumn 4, and t is 1). In the secnd test, it is i.{l.1 + iz.{l.1 (as the first eight were cvered in the first SUBSTRING). If a clumn is inserted in the middle f an existing table, then ur bitmask tests will n lnger be valid. The same reasn fr nt cding SELECT * applies here - ur related prcesses will n lnger wrk. if the clumn rder changes. Types f Trigger There are three main types f triggers that fire n INSERT, DELETE, r UPDATE actins. Like stred prcedures, these can als be encrypted fr extra security, and mre n this will be cvered in the next chapter. FOR This is the mst basic trigger fund in virtually all crpratins where versins f SQL Server prir t SQL Server 2000 exist. This syntax has been replaced with the AFTER trigger actin. AFTER This is the default definitin while creating a trigger. AFTER triggers will fire after checking the cncerned cnstraint nce the deleted and inserted tables have been created, after the data has been mdified, but befre it has been cmmitted t the database. Whether the underlying data mdificatin is surrunded by a BEGIN TRANSACTION r nt, it is nt until cmpletin f this trigger that the transactin takes effect. if we have NTEXT, TEXT, r IMAGE data types within ur triggered table, then we will nt be able t reference thse clumnsfrm the inserted and deleted tables. if we need t reference these data types, then it is necessary t use INSTEAD OF triggers. 206

12 Types f Trigger T demnstrate the AFTER trigger, we will place recrds int an audit table, which will be ppulated frm triggers n the rders table. Nte that nrthwind is used as the default database in all the cde snippets in this chapter. The descriptin f the table is: CREATE TABLE Orders_Audit ( OrderID INT, CustmerID NCHAR (S) NULL EmplyeeID INT NULL, OrderDate DATETIME NULL, RequiredDate DATETIME NULL ShippedDate DATETIME NULL, ShipVia INT NULL, Freight MONEY NULL, ShipName NVARCHAR (40) NULL, ShipAddress NVARCHAR (60) NULL, ShipCity NVARCHAR (15) NULL, ShipRegin NVARCHAR (ls) NULL, ShipPstalCde NVARCHAR (10) NULL ShipCuntry NVARCHAR (ls) NULL, DateAdded DATETIME NOT NULL DEFAULT GETDATE() The new clumn that was absent in the rders table is a simple DATETIME stamp f when the recrd was inserted. While creating audit recrds, it maybe necessary t recrd under which lgin the mdificatin was made, depending n hw ur users cnnect t the database. We can recrd which cnnectin made the mdificatin by using SELECT USER. There are ways f getting the UID int a trigger table, like having a user clumn n the underlying table that is ppulated using a parameter passed t the calling stred prcedure. The fllwing T-SQL cde will create a recrd f hw the mdified rders rws lked befre any update r deletin tk place Cnly the shipping r required dates are altered): CREATE TRIGGER tr_iud_orders ON Orders AFTER INSERT,UPDATE,DELETE AS BEGIN If either f these tw dates altered, then create the audit recrd -- If either are nt altered, then n audit recrd IF UPDATE(ShippedDate) OR UPDATE (RequiredDate) THEN INSERT INTO Orders_Audit (OrderID,CustmerID,EmplyeeID,OrderDate, RequiredDate,ShippedDate,ShipVia,Freight,ShipName,ShipAddress, ShipCity,ShipRegin,ShipPstalCde,ShipCuntry ) SELECT OrderID, CustmerID, EmplyeeID, OrderDate, RequiredDate, ShippedDate, ShipVia, Freight, ShipName, ShipAddress ShipCity, ShipRegin, ShipPstalCde, ShipCuntry FROM deleted END 207

13 Chapter 7: Triggers This is a case where we might wish t have mre than a trigger fr each actin, depending n hw we want t use the table; but if there will be a high vlume f inserts, cmpared t updates and deletes, we will slw dwn ur insertin as we will wrk with the deleted table that will have n rws. The trigger simply places a rw in the audit table; therefre, we might nt have an INSERT actin fire the trigger. We can make.a trigger as cmplex as we wish fr ur auditing. If we want t audit INSERT recrds, then we can mdify this trigger s that in the deleted table was 0, we can make the trigger insert rws int the audit table frm the inserted table. The dark side is that the first mdificatin t the rw will generate a duplicate rw f the same data. Therefre, if we want t mdify every rw in the audit table there is n straightfrward slutin, but we can have an indicatr n the audit table t shw whether the rw is an insertin, mdificatin, r deletin, and ignre any insertin recrds fr the unique key if there are any subsequent rws fr the key. Here, we have a table shwing hw the audit table and the underlying table will lk, fr each actin: Orders INSERT New rw N rw UPDATE Updated Rw Previus rws values DELETE N rw Previus rws values! AFTER triggers will nly fire if all cnstraints placed n the assciated table are valid. When building a trigger it is crucial that the cde des nt vilate any cnstraint validatin placed n a clumn if it cmpletes any data mdificatin. Otherwise, this will result in an errr. Ordering Trigger Actins We can have mre than ne trigger fr each actin, t make mdularisatin f functinality and maintenance f ur cde easier. Fr example, having a trigger specifically fr auditing recrds, such as creating an image f the recrd in an audit table, and anther t perfrm any business lgic validatin is better than having a single trigger t d bth. It is als pssible t define when the AFTER trigger shuld fire. If we have a trigger defined t fire first and wish fr a different ne instead, we will have t remve the existing first trigger befre adding a new ne. It is nt pssible t simply replace the name f the trigger. 208

14 Types f Trigger Taking the audit and business rules validatin scenari ne step further, we culd create an audit table with the same rules as the main table, and add a clumn fr DATETIME f the rw generated, and then anther clumn fr an audit message. If we have the audit recrd insertin as the first trigger, we can add in any business failure message int this recrd when the secnd business rules validatin trigger fires. Hwever, we can als have the audit trigger fire last s that all eventual mdificatins t the data are picked up. In additin, if any ther triggers cause a rllback, then n audit recrd will be created, which might be the scenari we wish t have. It all depends t hw we want t create audit recrds, and the better practice will be t have rllbacks in triggers t fire sner rather than later. Anther scenari culd be when a price rise is placed n inventry. A stred prcedure can run, which will update the tax value n each stck item. The first trigger can be an audit trail, the secnd trigger can check if the new cst f the item is abve a certain level and apply a new level f discunt r shipping charge, and a third can mdify a table hlding statistics n stck, value, taxatin levels, and s n. We can call sp_settriggerrder system stred prcedure t set the rder f triggers:! If there are three r mre AFTER triggers, thse nt named as itrst r last will itre in any rder. INSTEAD OF Until SQL Server 2000, it was nt pssible t have a trigger n a view. Prir t SQL Server 2000, a view was simply t prvide a specialized view n a set f data. Hwever, it is nw pssible t mdify the underlying data displayed in a view. Mdifying data thrugh a view desn't need a trigger necessarily, but it's use gives cntrl ver the mdificatins. By defining an INSTEAD OF trigger, we can prevent any mdificatins thrugh a direct T-SQL statement n a view, and cntrl thse mdificatins thrugh the trigger. INSTEAD OF triggers differ frm AFTER triggers as they run befre any cnstraint checking. Therefre, these can supplement any cnstraint checking, if required. Unlike AFTER triggers, we can nly define ne INSTEAD OF trigger per table r view. If we want t fllw the scenaris defined earlier in this sectin, with multiple triggers, then we can get the trigger t either have all the cde in ne place, r call ther stred prcedures if necessary. This als means that we cannt set a trigger default rder fr INSTEAD OF triggers, as there is nly ne. 209

15 Chapter 7: Triggers Althugh INSTEAD OF triggers fire befre cnstraint checks, we shuld nt replace cnstraints with triggers. Mre n this will be discussed in the Triggers Versus Cnstraints sectin. If we have cascading actins defined when a freign key is placed n the underlying tables, then we cannt have a crrespnding INSTEAD OF trigger defined. Therefre, if we have cascading DELETES, we cannt have an INSTEAD OF DELETE trigger. Cascading It is pssible fr ne trigger t alter data in anther table and the trigger n that table t fire. This is knwn as cascading triggers. Cascading triggers d nt exist n INSTEAD OF triggers, but nly n AFTER triggers. Cascading triggers execute in the sequence: If there are any cascading actins selected when creating a freign key n the table with the trigger, then these will fire first Then, the trigger assciated with the mdified table will fire Each table mdified in rder will then fire any trigger assciated with it Cascading triggers have bvius perfrmance hits n ur applicatin. We can use cascading triggers nly if a trigger is perfrming either sme audit actin r an update, such as summing a set f rders fr a prduct int a sales audit table. If the ptential cascading triggers perfrm nly validatin, then cascading shuld nt be allwed. T allw nested triggers, we need t cnfigure the database. This can be dne in T-SQL as: sp_cnfigure "nested triggers",l N Rws Updated A trigger will fire n the triggering actin even if n rws have been affected. Take a lk at the fllwing update trigger. This will fife n an UPDATE actin n the rders table. CREATE TRIGGER ON Orders AFTER UPDATE AS BEGIN t r _ u ~ O r d e r s N R w s RAISERROR('Update ccurred'.l.l) END 210

16 Transactins and Triggers If n rws in the rders table are actually updated, the RAISERROR statement will run. UPDATE Orders SET RequiredDate WHERE Custmerld Null 'NOROW' Once the abve cde is executed, we will see the fllwing utput. It lks as if a rw has been updated but the (0 rw(s) affected) line says that there have been nne. Msg 50000, Levell, State Update ccurred (0 rw(s) affected) The crrect methd f writing a trigger is t t check hw many rws were affected. We can d this as the first statement in the trigger, r by checking the deleted and inserted tables. H we want t check the triggered table, then we must put NROWCOUNT ItrSt in the trigger. Let's rewrite the abve trigger accrdingly t fire the trigger if n update ccurs: ALTER TRIGGER ON Orders AFTER UPDATE AS BEGIN 0 RETURN t r _ u p ~ O r d e r s N R w s RAISERROR('Update ccurred',l,l) END Transactins and Triggers It is pssible t wrk with transactins within a trigger issuing COMMIT TRANSACTION r ROLLBACK TRANSACTION statements. This may seem similar t having these statements within a T-SQL transactin, but it is nt s with ROLLBACK. Within a T-SQL batch, a ROLLBACK will und any changes made frm the start f the transactin, and prcessing will cntinue with the next statement after the ROLLBACK within the batch, r the next batch. 211

17 Chapter 7: Triggers If we issue a ROLLBACK within a trigger, the changes are undne fr the transactin including changes made in the trigger and the stred prcedure at the BEGIN TRAN statement, but the batch will terminate and prcessing will mve n t the next batch irrespective f any statements. The reasn behind this can be seen in this sectin f dummy cde: BEGIN TRANSACTION UPDATE TableA SET Clumn4 = Value1 WHERE clumn1 = Value2 INSERT INTO TableA (Clumn1,Clumn2,Clumn3,Clumn4) VALUES (1,2,3,4) COMMIT TRANSACTION SELECT Clumn4 FROM TableA If we have a trigger n TableA and a prblem arises within this batch, SQL Server will nt assume that we have an UPDATE trigger, INSERT trigger, r bth. The trigger with the ROLLBACK statement may be any f the nes set up fr TableA, r n any cmbinatin f table updates. Therefre, the trigger itself may have been fired fr the UPDATE r the INSERT. If a ROLLBACK is issued frm the trigger, then SQL Server will nt knw whether it is allwed t run the INSERT r any further statements, s it takes the safe rute and will nt run the SELECT statement either (in the example). Trigger versus Cnstraints When it cmes t enfrcing integrity, we have t get the right tl fr the right jb. Later in the Gd Practices sectin, we will lk at gd and bad practices fr triggers and talk abut the right tls there. One f the issues is enfrcing the different levels f integrity, ne f which is dmain integrity, enfrced thrugh CHECK cnstraints. Enfrcing dmain integrity thrugh CHECK cnstraints is nt always pssible. Freign key cnstraints may als prvide insufficient prcessing cmplexity and this is where a trigger fits in. We will use a trigger instead f a CHECK cnstraint when the validatin required is nt against anther clumn within the table r a value. S if we had an rder ttal which checks that the ttal matched the rder plus tax and shipping, which cannt be dne as part f a CHECK cnstraint. Instead, we will have a trigger that fires when the rder table is updated r inserted, and validates thse specific clumns. Validating against a clumn in anther table culd be dne in a case where clients are given credit rating. When an rder is being placed, a jin t the credit rating table frm the client table is placed and a check is made that the client has enugh credit t place the rder. We will cmpare the value in the client table's credit utstanding clumn with the level in the credit rating table, t ensure that it falls within acceptable bunds. 212

18 Triggers versus Stred Prcedure Finally, when wrking with a CHECK cnstraint, if an errr ccurs, we have n cntrl ver the message; this depends n the SQL Server. If we wished t have a custm errr message, we will have t implement this thrugh a trigger, but if it is pssible t stick with the generic message, then d s. Triggers versus Stred Prcedure We may ask why nt use a stred prcedure instead f a trigger? Well, there may be times when it is the mre apprpriate chice, as the stred prcedure cde will wrk with sets f data at a time, while the trigger will wrk with rws f data at a time. Therefre, any validatin r extra prcessing when a recrd is mdified can be perfrmed in the trigger, rather than altering the stred prcedure t use a cursr, r cmpleting a pass-thrugh f the recrds at least twice - nce fr validatin and then fr an update. It may be pssible t have sme f the validatin in the JOIN and WHERE statements, but this may nt cver every scenari. In additin, we can get the exact clumns that have been mdified with a trigger and see the value befre r after any clumn, which can aid in the validatin. The main difference between triggers and stred prcedures is that stred prcedures are cntrlled and invked by the user, whereas triggers are cntrlled ttally by the actins perfrmed n the underlying table, and we have n cntrl ver their firing except drpping them. Finally, by using a trigger rather than placing the validatin within a stred prcedure, we can have the validatin r any further script actins in a central place. Therefre, as the database wner, when an ad-hc query is being executed, r a number f different stred prcedures mdify the same underlying table, we can be assured that the business validatin is being perfrmed. This is an uncmmn, but useful scenari fr mre cmplex stred prcedures, where we attempt t debug the activities f the stred prcedure in the temprary table. If the stred prcedure is updating a table at several pints within a prcedure, we might be able t see which sectin f the stred prcedure has the prblem, and the time when the prblem ccurred, by having an audit trigger. Replicatin Althugh we are nt here t teach replicatin, it is necessary t knw a bit abut replicatin, if ur database cntains triggers. We will cver the mre salient pints when lking at replicatin with user-defined triggers. 213

19 Chapter 7: Triggers Three pssible types f replicatin are pssible: Transactinal- We have ne master database, the publisher, where all changes are made and are passed t the subscribers, which are any ther databases set up t receive any replicated infrmatin. Merge - We still have a publisher database that sends ut changes, but the subscribers can als send ut changes. Snapsht - The publisher database is cpied as a whle t all subscriber sites. With snapsht replicatin, triggers are nt a prblem as the whle database is replicated as a snapsht at a particular time, hwever we have t design carefully with the ther tw. With transactinal replicatin, we will be aware f what data is being replicated and hw. Triggers n the subscribers d nt need t cntain any business validatin necessarily, but cntain updates t tables that are nt replicated, such as tables in a different database. Finally, with merge replicatin, we will have triggers n bth tables with business rules and cascading actins. When data published n ne system prpagates thrugh t the replicated systems, any trigger in place has t cater t data cming either frm its wn system, r frm replicated data. Merge replicatin use triggers created by the Snapsht Agent t place any changes in the replicated tables int the system replicatin defined tables. When replicatin is created fr a table that is defined as immediate r queued update subscriber, then the replicatin sets up a default trigger that will fire first. Therefre, any change cmpleted n that table will be replicated befre any ther trigger, when replicatin is allws subscriber databases t mdify data t be passed back t the publisher database. Immediate r queued update subscriber is an update mde fr subscriber databases t replicate any changes t the publisher. One ther pint t nte is that the nested trigger ptin must be enabled while using immediate r queued update subscriber replicatin. This is the default setting, but if we have disabled this ptin as sme srt f safety check in ur system, we will have t enable it again.! If we already have a trigger defined as the first trigger, we must remve this befre making the table an immediate r queued update subscriber, therwise an errr will ccur. We cannt make any ther trigger a first trigger, nce this replicatin is set up. 214

20 Recursin While replicating, any trigger that has been defined as WITH ENCRYPTION will never be published. We either have t remve the encryptin, which is prbably nt the best actin, r manually place the trigger n each subscriber with the encryptin included. If we have user-defined triggers n the subscriber database, they have t be replicated t ensure that they are really needed there. We may find that mving the lgic t the stred prcedures defined fr the replicatin itself makes the cde mre efficient, but will have t be cntrlled in a very tight surce cde fashin if we ever have t recreate the database with replicatin, fr example when mving frm a test setup t the live setup. Preferably, this ptin f mving cde shuld nly be cnsidered if we find the replicatin slw, and there are lags in the updates. Recursin As with stred prcedures, we can set up recursive triggers. Althugh rare, there can be scenaris when this can be acceptable. We saw a direct recursin with the Factrial stred prcedure in Chapter 1, it is pssible t have recursin n triggers as well. There are tw types f trigger recursin: direct - A trigger updates the same table that the trigger has been fired n and therefre fires itself again. indirect - A trigger is fired n ne table, which updates a different table with a trigger n it, which then updates the riginal table again. T clarify the indirect trigger, ne example wuld be when a new rder cmes in, and a trigger fires which updates the stck levels. This fires a trigger n the Stck table t reduce the stck level. If the stck falls belw a certain level, then this might update the rder table with an indicatr that we are ut f stck. This will re-fire the trigger n the rder table. In this scenari, we have t be careful nt t end up in an endless lp, and fire the update n the Stck table nly if there is a stck mvement. The secnd time the rder trigger is fired this will nt be the case, and therefre we will test this, and just let the trigger recursin stp. T enable direct recursin t take place, then we need t set the RECURSIVE_TRIGGERS SQL ptin t ON. ALTER DATABASE Nrthwind SET RECURSIVE_TRIGGERS ON As sn as we place a trigger n a database, whenever anther trigger is added, there is always the danger that recursin culd exist. Keep this in mind, it is better t have RECURSIVE_TRIGGERS set t OFF, and ensure that we d nt cde a 'cver all' and blt dwn what the trigger is actually there jar, while building it. 215

21 Chapter 7: Triggers If we have a trigger that updates the same table that caused its firing, then the same trigger will fire again if RECURSIVE_TRIGGERS was ON. If we d have this ptin n, and we are updating the same table, perhaps with summary inf, then we have t cnsider the fact that recursin will ccur and cde defensively fr it, therwise we may get int an infinite lp. Gd Practice The mst imprtant pint is t keep the trigger as shrt as pssible t execute quickly, just like stred prcedures. The lnger a trigger takes t fire, the lnger the lcks will be held n the underlying tables. T this end, we culd place cursrs within a trigger, but gd practice dictates that we dn't. Cursrs are nt the fastest f bjects within a database, and we shuld try and revisit the prblem with a different slutin, if we feel the need fr cursrs. One way arund the prblem may be t run tw, r perhaps, three updates, r even use a temprary table instead. Use triggers t enfrce business rules, r t cmplete actins that have either a psitive effect n the rganizatin, r if an actin will stp prblems with the system. An example f this is creatin f a trigger that will a client when an rder is abut t be shipped, giving details f the rder, and s n. Use where required, t check the number f rws that have been affected. If we have a trigger n a table, watch ut if ur cde invking the trigger uses value. If we have a stred prcedure that inserts an rder and t give the rder number created, and we have an audit trigger that inserts int the audit table, which als has an IDENTITY clumn, value returned by the stred prcedure will be that frm the audit table and nt the rders table. T get arund this, we will perhaps have t use a MAX () functin t find the last rder ID. Bad Practice Firstly, dn't substitute a cnstraint with a trigger, as we cvered much f this in the Triggers Versus Cnstraints sectin. Within a database slutin, there are different levels f integrity, and at each level, there is an apprpriate methd f enfrcing that integrity. Entity Integrity - N rw has a NULL in the primary key, all tables have primary keys, and n tw rws have the same primary key value. The slutin t enfrcing this is t build a primary key as a UNIQUE cnstraint, and n clumn that frms the primary key allws NULLS. 216

22 Summary Dmain Integrity - When all values in a specific clumn are valid, whether this is a range f values r specific values, the slutin is t place a cnstraint n a specific clumn, knwn as a CHECK cnstraint Referential Integrity - Where all freign keys are valid, the slutin is t place freign key cnstraints n the relevant tables. These slutins fr each integrity type will cver mst scenaris. We will cnsider using a trigger nly when they are nt sufficient. It is unusual, if nt rare, t run int a different database slutin, and find that triggers have replaced these natural methds f enfrcing integrity. Althugh verheads f using triggers are lw nrmally, we create a perfrmance verhead if we use a trigger when ne f these ptins wuld have been sufficient. Therefre, any cde vilating these recmmendatins shuld be remved and replaced. There are ther prblems with a ROLLBACK in a trigger t if we use cursrs and nested transactins; we lked at sme f the prblems in Chapter 3. There are n restrictins n the T-SQL cde placed within a trigger. Therefre, it is pssible t place a SELECT statement within cde t return a rwset, which is an unusual actin, since we shuld return data within a stred prcedure when we need t. Summary Triggers are excellent tls fr a develper t have when building a database slutin. Care has t be taken that the right trigger and the right cde is placed within a trigger thugh. But the skill lies in knwing when t have cascading triggers, whether t wrk with transactins within a trigger, what t d when replicatin is invlved, and what islatin levels t have. Once a database slutin is in place with wrking triggers, any alteratin t that database envirnment, such as replicatin, will require a great deal f thught and planning. Testing shuld be intensive with an emphasis placed n areas such as perfrmance. We may need t alter what happens within triggers, and maybe even split an AFTER trigger n ne table actin int tw, with nly ne wrking n the replicatin. 217