To read the article online, visit http://www.4GuysFromRolla.com/webtech/010600-1.2.shtml

Writing a Stored Procedure Part II, Part 2

By Nathan Pond


  • Read Part 1

    In Part 1, I introduced a lot of new things, so lets slow down for a minute and I'll go through them. First thing I did was create a command object for ADO. I did this with:

    Set adocmd = Server.CreateObject("ADODB.Command")

    Next I had to tell the object what command it would be executing, with this line:

    adocmd.CommandText = "sp_IsValidLogon"

    Notice that the command is the name of the stored procedure. You must tell the command object which connection (database) to use, to do this you use .ActiveConnection. .CommandType is a property that tells sql what type of command it is trying to execute. adCmdStoredProc is a constant variable declared in the include file adovbs.inc. (For more information on adovbs.inc, be sure to read ADOVBS.INC - Use It!) It represents the number telling sql that the command is to execute a stored procedure. The .Append method is used to add return values and parameters. I had to add the username and password parameters, as well as set up the return value. I then executed the command with .Execute, and .Parameters("return").Value held the return value from the procedure. I set that to the variable IsValid. If IsValid is 0, the login is incorrect, if it is 1, the login is correct.

    Now even after the explanation this is still a lot to take in. My recommendation to you is to dive into your server and try a few simple tasks like this. Practice makes perfect. One note: sometimes I get errors when I try to .Append the return value after I have already set the parameters. Meaning I might get an error if the above code looked like this:

    <%
    .....
    Set adocmd = Server.CreateObject("ADODB.Command")
    adocmd.CommandText = "sp_IsValidLogon"
    
    adocmd.ActiveConnection = dataConn
    adocmd.CommandType = adCmdStoredProc
    adocmd.Parameters.Append adocmd.CreateParameter("username", _
                adVarChar, adParamInput, 16, Request.Form("UserName"))
    adocmd.Parameters.Append .CreateParameter("password", _
                adVarChar, adParamInput, 16, Request.Form("Password"))
    adocmd.Parameters.Append .CreateParameter("return", _
                adInteger, adParamReturnValue, 4)
    adocmd.Execute
    
    IsValid = adocmd.Parameters("return").Value
    .....
    %>
    

    I'm not exactly sure why this happens, but I just made it a habit to declare the return value first, then the parameters.

    Now I know what some of you are saying. "The original ASP example for checking the username and password without using a stored procedure is so much easier, all you did was confuse me! Can Stored Procedures actually be used to improve efficiency?" Well I'm glad you asked, because although the example above did require a bit more code, it is important to realize that it is much more efficient. Stored procedures have other benefits besides efficiency, though. For a full explanation of the benefits of stored procedures, be sure to read the SQL Guru's Advice on the issue. And now I am going to show you an example of a task where using stored procedures minimizes your database calls.

    Assume you have the same script as before for validating usernames and passwords. All it really does is say whether it is a valid username and password. Suppose you want to add functionality in to log all failed attempts at logging on into another table called FailedLogons. If you weren't using a stored procedure you would have to make another call to the database from your ASP code. However, in the example using the stored procedure, we don't have to touch the ASP code at all, we simply modify the procedure like so:

    ALTER PROCEDURE sp_IsValidLogon
      @UserName  varchar(16),
      @Password  varchar(16)
    As
    if exists(Select * From User_Table 
              Where UserName = @UserName
                            And
                    Password = @Password)
      begin
        return(1)
      end
    else
      begin
        INSERT INTO FailedLogons(UserName, Password)
            values(@UserName, @Password)
    
        return(0)
      end
    
    Go
    

    Wasn't that neat? But that's not all, while we're at it why not add a little more functionality? Let's say that we want to run a check on each incorrect login, and if there have been more than 5 incorrect logins for that username within the past day, that account will be disabled. We would have to have the FailedLogons table set up to have a dtFailed column with a default value of (GetDate()). So when the incorrect logon is inserted into the table, the date and time is recorded automatically. Then we would modify our stored procedure like this:

    ALTER PROCEDURE sp_IsValidLogon
      @UserName  varchar(16),
      @Password  varchar(16)
    As
    if exists(Select * From User_Table
              Where UserName = @UserName
                            And
                    Password = @Password)
      begin
        return(1)
      end
    else
      begin
        INSERT INTO FailedLogons(UserName, Password)
            values(@UserName, @Password)
        
        declare @totalFails  int
        Select @totalFails = Count(*) From FailedLogons
            Where UserName = @UserName
            And dtFailed > GetDate()-1
    
        if (@totalFails > 5)
          UPDATE User_Table Set Active = 0
          Where UserName = @UserName
    
        return(0)
      end
    
    Go
    

    Now, let's take a closer look at what I was doing. First thing, check to see if the username and password exist on the same row, if they do, login is fine, return 1 to the user and exit the procedure. If the login is not ok though, we want to log it. The first thing the procedure does is insert the record into the FailedLogons table. Next we declare a variable to hold the number of failed logons for that same day. Next we assign that value by using a sql statement to retrieve the number of records for that username, within the same day. If that number is greater than 5, it's likely someone is trying to hack that account so the the username will be disabled by setting the active flag in the User_Table to 0. Finally, return 0 letting the calling code (ASP) know that the login was unsuccessful. To accomplish this same task using only ASP, you would have needed to make 4 database calls. The way we just did it it is still only one database call, plus the fact that all that functionality we added at the end was in the stored procedure, we didn't have to touch the ASP code at all!

    Note about begin/end: When using an If statement in a stored procedure, as long as you keep the conditional code to one line you won't need a begin or end statement. Example:

    if (@myvar=1)
      return(1)
    else
      return(2)
    

    However, if you need more than one line, it is required that you use begin and end. Example:

    if (@myvar=1)
      begin
        do this.....
        and this.....
        return(1)
      end
    else
      begin
        do this....
        return(2)
      end
    

    I hope that I have given enough information to keep you active in learning stored procedures. If you're anything like me, getting the basics is the hard part, from there you can experiment and learn on your own. That is why I decided to create these two articles. Remember, feel free to e-mail me at npond@bgnet.bgsu.edu with any questions or comments about either of my articles. And thanks to everyone who wrote to me regarding part one of this series.

    Happy Programing!

  • By Nathan Pond

  • Read Part 1


  • Article Information
    Article Title: Writing a Stored Procedure Part II, Part 2
    Article Author: Nathan Pond
    Published Date: Thursday, January 06, 2000
    Article URL: http://www.4GuysFromRolla.com/webtech/010600-1.2.shtml


    Copyright 2017 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers