ASP Primer: Making a Request
Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js
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.
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?
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.