Implementing logging on DELETE
Video: Implementing logging on DELETEFor our DELETE stored procedure, the rules we're going to implement is the stored procedure can only delete one record at a time, and we must maintain a log of who deleted and when. So in order to maintain that log I'd like to create a new table that will be used for that logging. I have some code staged for that. It's a three column table; one column for user name, the person who did the deletion, one column for the ID that they deleted, and one column for the date. I also have some codes staged for the stored procedure. So starting at the top we have with CREATE PROCEDURE Students_Delete.
- Next steps
Viewers: in countries Watching now:
This course investigates several key database-programming concepts: triggers, stored procedures, functions, and .NET CLR (Common Language Runtime) assemblies. Author Martin Guidry shows how to combine these techniques and create a high-quality database using Microsoft SQL Server 2012. The course also covers real-world uses of the INSERT, UPDATE, and DELETE procedures, and how to build a basic web form to connect to your database.
- Comparing triggers, functions, and stored procedures
- Installing and configuring SQL Server
- Creating a stored procedure
- Returning data using data sets
- Creating user-defined functions
- Using "after," "instead," and nested triggers
- Modifying existing stored procedures
- Implementing logging on DELETE
- Choosing between T-SQL and CLR
- Executing a stored procedure
- Passing parameters
Implementing logging on DELETE
For our DELETE stored procedure, the rules we're going to implement is the stored procedure can only delete one record at a time, and we must maintain a log of who deleted and when. So in order to maintain that log I'd like to create a new table that will be used for that logging. I have some code staged for that. It's a three column table; one column for user name, the person who did the deletion, one column for the ID that they deleted, and one column for the date. I also have some codes staged for the stored procedure. So starting at the top we have with CREATE PROCEDURE Students_Delete.
This time we are only taking one parameter. All I need is the ID of what you would like to delete. Line number 2 there is new to us. We're saying EXCUTE AS CALLER. There are some context in which a stored procedure might execute as the system, but in this one, one of my business requirements is to log who is running this. So I am going to specifically saying EXCUTE AS CALLER. Line 6 through 11 we check to make sure that this ID already exists and make sure it only exists in the database once. Now we did something very similar to this in the INSERT stored procedure, and the UPDATE stored procedure.
Now we're going to have it a third time in the DELETE stored procedure. This is becoming a little displeasing to me to have an essentially the exact same code running in three different places. So I'm going to use a technique we talked about earlier in this course of simplifying our lives. I am going to create a function that performs all of this and that way we'll just be able to use the function. We won't have to maintain the exact same code in three different places. So we'll take a slight detour and I'll pull up the code I had for the function. So this is a function that is going to count the number of times that a certain ID exists in our students table.
The only parameter you have to pass to it is an ID. The ID you're in fact looking for. It'll return an integer, a single integer saying how may times does this ID occur. Execute that, command(s) completed successfully. That's good news. So now I'll go back to the stored procedure and replace that code. This code that appears in three different places. I want to simplify my life and get rid all that. All I need to check on is the value of this. So that code will pass the ID in question to the function called Count IDs, and that function will return the number of times that ID occurs in our table.
Beyond that, things are fairly straightforward. Line 50 and 16 will perform the delete. Line 20 checks to see if we did in fact delete exactly 1 record, and if we did we need to meet our other business requirements of logging who did the deletion. So line 22 and 23 will insert a new record into Student_Delete log. The values we are looking for is suser_ sname which is a SQL Server variable that stores the name of who is running the stored procedure. The next thing we pass to it is the ID that was deleted, and the last thing we pass is the current date.
Let's go ahead and run that and that gives us one stored procedure for deleting a student, one stored procedure for inserting a student, and one for updating a student. We have nice a little package of all of the things we're likely to perform on a student. Go ahead and test the delete functionality. It says one row affected so that should have deleted that ID from the student table, and yes, in fact that record is gone.
We also said we we're going to log this. So let's check to make sure our log is functioning properly, and we see one record in there, User Name Martin, deleted the ID 123456. There is the date the record was deleted. So we have successfully implemented all of the business rules for a DELETE stored procedure.
There are currently no FAQs about SQL Server: Triggers, Stored Procedures, and Functions.