Instead of Update

Today, I will be looking at how INSTEAD OF TRIGGERS can be used to make our VIEW correctly work with a UPDATE statement.

I will be using the [AUTOS] sample database for this demonstration. The [VW_JOIN_MAKES_2_MODELS] view will be enhanced with a instead of trigger so that update action can be perform on two tables at the same time.

The enclosed script has code to perform the following actions in the AUTOS database.

5A – Remove aggregate view
5B – Reload tables with good data
5C – Create a instead of trigger (insert)
5D – Test insert actions of instead of trigger
5E – Create a instead of trigger (delete)
5F – Test delete actions of instead of trigger
5G – Create a instead of trigger (update)
5H – Test update actions of instead of trigger


Our focus today will be on 5G – defining the instead of update trigger and 5H – performing unit testing on said trigger.

Like most Data Definition Language (DDL) constructs, a user defined trigger has three operations associated with it: CREATE TRIGGER, ALTER TRIGGER and DROP TRIGGER.

Since our view joins data between two tables, we need to know if data is going to be updated from the 1 = MODELS, 2 = MAKES or 3 = BOTH tables.

With the instead of update trigger, we could compare the new data in the inserted table to the old data in the deleted table to determine what action to perform. This would require a lot of code for a view with a bunch of fields.

How do we determine what table to update using a limited amount of code?

We are in luck since the DBCC INPUTBUFFER command can help us. Calling this function with the current session id returns a table containing information about the event. I used a table variable below to hold the information. We can find the exact TSQL statement that was used when the trigger fired.

By parsing this string, we can find the WHERE clause of the update statement. Thus, finding what table to update from.

Here are some ground rules for our view users. One requirement of the user is to use the primary key (make id or model id) or natural key (make name or model name) in the WHERE clause. Only fields other than the primary key will be updated. Any broken requirements will end up in a error.

The code below defines the INSTEAD OF UPDATE trigger.

Lets get the negative testing out of the way by trying to update data from the view without a primary key.

The first positive test is to update data in the MAKES table using a primary key.

The second positive test is to update data in the MODELS table using the primary key.

The third positive test is to update data from both the MAKES and MODELS tables at the same time works. This is a new functionality that is not available in a normal view.

In summary, we were able to add a INSTEAD OF UPDATE trigger to our user defined view to make it function correctly with a UPDATE statement. While I have been focusing on enabling a VIEW to be updatable, triggers can be used to implement many different business rules.

Just remember, a trigger gets fired like a Tommy Gun every time the associated DML statement (INSERT, UPDATE, DELETE) is executed. Therefore, limiting the amount of code in a trigger will make sure your SQL statements execute as quick as possible.

Next time, I will be creating a test data warehouse from scratch with 20 million rows. This in preparation for partitioned and materialized views.

Related posts

Leave a Comment