Instead of Delete

Today, I will be looking at how INSTEAD OF TRIGGERS can be used to make our VIEW correctly work with a DELETE 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 delete 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 5E – defining the instead of delete trigger and 5F – 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 deleted from the 1 = MODELS, 2 = MAKES or 3 = BOTH tables.

With the instead of insert trigger, we could use the physical data in the inserted table to determine what action to perform. The instead of delete table has the deleted table for reference; However it only shows potential records affected by the delete statement.

How do we determine what table to delete from?

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 delete statement. Thus, finding what table to delete from.

Here are some ground rules for our view users. One requirement of the user is to use the primary key (make or model id) or natural key (make or model name) in the WHERE clause. Deleting from the model table has no dependencies. Deleting from the make table can only occur if no model records exist. An exception to this rule is a delete from both tables when only one record exists in both. Any broken requirements will end up in a error.

The code below defines the INSTEAD OF DELETE trigger.

Before testing the new trigger, I want to add another model record (child) to the maker table (parent). This means on data relationship with have an 1 to 2 cardinality.

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

The first positive test is to delete data from the MODELS table using either the natural or primary key.

The second positive test is to delete from the MAKES table using the natural key. We have to make sure no child record exists.

The second negative test is delete data from from the MAKES table using the primary key with one existing child record. This is a no-no according to the rules.

The third positive test is to validate that deletion of 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 DELETE trigger to our user defined view to make it function correctly with a DELETE statement. While the next article focus on making our view work correctly with an UPDATE statement, these trigger can be used for other purposes.

For instance, when designing a system that keeps track of large money transactions, we never want to actually delete a record. We just want to mark it as deleted just incase the action taken by a high level user was fraudulent. This would be another pefect use of this trigger.

Related posts

Leave a Comment