ASP Primer: Making a Request

• facebook
• twitter
• in
• Email

Use these bookmarks to jump around the tutorial:

[Request.Cookies: Getting Stuff Out of a Cookie

[The Handy Dandy Session Variable]

[Request.QuryString: Passing Information Along]

[What's Next?]

 

The Handy Dandy Session Variable

 

Variables? I thought we already talked about variables?

 

Well, we talked about "normal" variables. Session Variables are in a league all their own. Session Variables are also very closely tied to cookies, which is why I waited until now to present them to you. In many ways Session Variables have a great deal more power and flexibility than regular variables but there are some drawbacks as well.

 

As you already know, variables have a limitation of only being usable on the page that they are created on. They are local to the page. For example, if you set variable "my_cash" equal to "$22.00" on an ASP page and then refreshed the page or moved on to another page, the value of "my_cash" would vanish. In fact, as soon as the page finishes sending everything to the browser, the values in all of your variables cease to exist. That is not true of Session Variables.

 

With a Session Variable you can move a value from page to page. While Session Variables hold values just like any other variable, they have very different implementations and requirements. Here are the key differences:

• You don't have to declare a Session Variable with a Dim statement. By referencing a Session Variable you will create it if it does not already exist.

• Session Variables require that the user have cookies capabilities available and turned on.

Here's an example of how to create and use a Session Variable:

 

<% Session("my_cash") = "$22.00" %>

 

In the example above we are creating a Session Variable named "my_cash" and setting it equal to "$22.00". In this one line we have created the Session Variable and assigned it a value.

 

Retrieving the value is just as straight-forward:

 

<% Response.Write "I have " & Session("my_cash") %>

 

So, what happens if you retrieve a Session Variable value before it is assigned a value?

 

You end up actually creating a Session Variable that has no value in it. If we used the example from above, "my_cash" would have been created when the Response.Write was executed. It would have no value, though, since we were simply retrieving the value.

 

So, why do cookies have to be turned on?

 

It's because cookies are the base technology for Session Variables. You see, ASP uses temporary cookies to store your Session Variable values. It does this by creating a cookie with a unique name that the server makes up. Each time a Session Variable is referenced its value is retrieved from that temporary cookie. The cookies are temporary because they only last while the user is having an active session. If the user has left the site or walks away from their computer for more than 30 minutes, the session is considered over and the cookie is removed. If the user doesn't accept cookies at all then there is no place to store the Session Variable values, therefore, no way to maintain the values from page to page.

 

By the way, the session time-out can be changed to be longer or shorter than 30 minutes. We'll get to that little trick later in the series when we get to the object that controls session time.

 

So, why not use Session Variables all of the time?

 

Most every ASP developer I know will tell you to avoid Session Variables when at all possible. They may seem like the easiest solution for everything, however, they have some definite drawbacks.

 

They add a lot of additional communication traffic and overhead. Each time a Session Variable is referenced, the server has to go and retrieve the information from the special cookie. While this may not seem like a big deal, you can imagine what a nightmare it would be for a server to track hundreds or thousands of users, each with unique Session Variables. It can put quite a strain on the server.

 

So, when is a good time to use a Session Variable?

 

Session variables are perfectly fine to use as long as you use them sparingly. The best example that I can think of is when securing pages. You can use a Session Variable to grant access to secured pages by setting a single Session Variable to a secret access value. Then each time a new ASP page is accessed, it first checks to see of that Session Variable's value is correct for access. If it isn't, the user is directed to a login page. If it is, the page is displayed. This will be our practical example in the next installment of this series.