Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Now I'd like to demonstrate some more complex stored procedures. These are the types of procedures I commonly see on large databases in the real world. They implement business rules as well as enforce data integrity requirements. In order to execute the examples in this section we'll need a new table. I have a text file of data in your folder of exercise files. Let's import that data now. I'll right-click on myDatabase, go to Tasks, and near the bottom we have Import Data. On this screen I'll click Next.
The first question it asked me is, what's my data source? My data source will be a Flat File and I'll browse to that file now. It's in the Chapter 6 section of your exercise files. This dialog box defaults to text files. What I want is want is actually a CSV, so there we will pick up students.csv, and now it's just a whole bunch of Next, Next, Next, Next, Finish. And I get a bunch of green check mark saying Success. That seems good.
I'll hit a refresh here and I have a new students table. Let's go ahead and look at some of that data. We have things like a student ID, last name, first name, state, some other contact information including an email address, a graduation year, GPA, and a yes or no on whether or not they would like to receive our email newsletter. Great! Now that we have data to work with the first stored procedure I'll implement is an insert stored procedure. I'm going to make up the following fairly plausible hypothetical rules about inserting.
When inserting, every ID must be unique. It's something that could be handled by the database automatically, if it was automatically assigning IDs, but in this hypothetical I'm going to say different system is assigning IDs and as they come in to my system, I want to double-check and make sure they're unique. Also, things like a GPA must be between 0 and 4 with no more than two decimal places. That's something that a front-end application should handle, but it doesn't hurt for me to double-check it. Let's say hypothetically someone else is writing the front-end application and they are either unwilling or unable to make this check.
Then I'll check it on the way into the database and we're going to return a 1 for success or 0 for failure. So I have a stored procedure stage already in your Exercise folder. It significantly longer than some of the stored procedures we've worked with earlier. So I'll walk you through it. We start off of course with keyword, create keyword procedure, and then we have to accept quiet number of parameters. The number of parameters I am accepting is exactly the same as the number of columns in the table. I need one parameter for each field we're going to insert.
Scrolling down a little right after the BEGIN statement, the first I want to do is check to make sure the ID does not already exist in the database. So that's one of my business rules. We have to have unique IDs. So line 18, 19, 20, 21 will perform a query to see how many times this ID already exists. Line 23 checks to see if that number is greater than 0. If it is, it raises an error and returns 0. That is exactly the desired functionality. Once that happens, the code will move on to line 31, 31, 32, 33.
We will format our GPA as two decimal places. That was one of our business requirements and then line 36, make sure the GPA is within a certain range. If the GPA is greater than 4 or less than 0, I am going to return an error to the user again. If we pass that check we're down to lines 44 where it's time to actually attempt the insert, fairly straightforward, INSERT statement. The very last thing I do is check to see the value of a variable @@ROWCOUNT.
This as a very variable I did not create. SQL Server automatically creates and the updates this variable with how many records were modified by the previous statement. If everything worked properly, I should've modified exactly 1 row. So if that value does =1, I'll return a 1 to the user indicating success of the stored procedure. So we'll go ahead and execute that, command(s) completed successfully. I always like hearing that. So there's my stored procedure, Students_Insert.
Now let's go ahead and execute this. I also have a little code stage for you for that. So I am going to try to insert the values, ID 123456, last name Guidry, firstname Martin, some basic contact information there. Notice that 7.1; I am intentionally trying to insert bad data. I am claiming that my GPA is 7.1. Obviously, very ambitious. If our stored procedure functions properly, it should return an error. So let's go ahead and execute. Look at that! It says GPA is invalid.
That is a good catch. So I'll change that to a more realistic value and we will try to run it again, and now it's says one row affected. That likely means success. I'll go check the database here in just a second, but I am going to run it again and it should say ID already exists. So it successfully did the insert the first time. If I try to run it again, it stops me saying this would be a duplicate ID, which is a bad thing. Just to make sure it actually got in there. Let's go ahead and query the table.
That returns exactly 1 row. That's good news. We'll scroll over. You see my GPA there formatted to two decimal places. That was one of the requirements. So it seems like everything is working great.
Get unlimited access to all courses for just $25/month.Become a member