User:Hauschbc/sandbox

= Row and Statement Level Triggers = To understand how trigger behavior works, you need to be aware of the two main types of triggers; these are Row and Statement level triggers. The distinction between the two is how many times the code within the trigger is executed, and at what time.

Suppose you have a trigger that is made to be called on an UPDATE to a certain table. Row level triggers would execute each time a row is affected by the UPDATE. It is important to keep in mind if no rows are affected by the UPDATE command the trigger will not execute any code within the trigger. Statement level triggers work similarly but they will be called once regardless of how many rows are affected by the UPDATE. Here it is important to note that even if the UPDATE command didn’t affect any rows, the code within the trigger will still be executed once.

Using the BEFORE and AFTER options determine when the trigger is called. Suppose you have a trigger that is called on an INSERT to a certain table. If your trigger is using the BEFORE option, the code within the trigger will be executed before the INSERT into the table occurs. A common use of the BEFORE trigger is to verify the input values of the INSERT, or modify the values accordingly. Now let’s say we have a trigger that uses AFTER instead. The code within the trigger is executed after the INSERT happens to the table. An example use of this trigger is creating an audit history of who has made inserts into the database, keeping track of the changes made. When using these options you need to keep a few things in mind. The BEFORE option does not allow you to modify tables, that is why input validation is a practical use. Using AFTER triggers allows you to modify tables such as inserting into an audit history table.

When creating a trigger to determine if it is statement or row level simply include the FOR EACH ROW clause for a row level, or omit the clause for a statement level. Be cautious of using additional INSERT/UPDATE/DELETE commands within your trigger, because trigger recursion is possible, causing unwanted behavior. In the examples below each trigger is modifying a different table, by looking at what is being modified you can see some common applications of when different trigger types are used.

After Each - Row Level Trigger
Here is an Oracle syntax example of a row level trigger that is called AFTER an update FOR EACH ROW affected. This trigger is called on an update to a phone book database. When the trigger is called it adds an entry into a separate table named phone_book_audit. Also take note of triggers being able to take advantage of schema objects like sequences , in this example audit_id_sequence.nexVal is used to generate unique primary keys in the phone_book_audit table.

Now calling an UPDATE on the phone_book table for people with the last name 'Jones': Notice that the phone_number_audit table is now populated with two entries. This is due to the database having two entries with the last name of 'Jones'. Since the update modified two separate row values, the created trigger was called twice after each modification.

After - Statement Level Trigger
Here is an example of an Oracle syntax statement trigger that is called after an UPDATE to the phone_book table. When the trigger gets called it makes an insert into phone_book_edit_history table.

Now lets do the exact same update as the above example, however this time we have a statement level trigger.

You can see that the trigger was only called once, even though the update did change two rows.

Before Each - Row Level Trigger
In this example we have a BEFORE EACH ROW trigger that modifies the INSERT using a WHEN conditional. If the last name is larger than 10 letters, using the SUBSTR function we change the last_name column value to an abbreviation. Now lets perform an INSERT of someone with a large name.

You can see that the trigger worked, modifying the value of the INSERT before it was executed.

Before - Statement Level Trigger
Using a BEFORE statement trigger is particularly useful when enforcing database restrictions. For this example I am going to enforce a restriction upon someone named "SOMEUSER" on the table phone_book.

Now when "SOMEUSER" is logged in after attempting any INSERT this error message will show: Custom errors such as this one has a restriction on what the num variable can be defined as. Because of the numerous other pre-defined arrors this variable must be in the range of -20000 to -20999.