Dealing with Stateless Programming One of the big differences lies in the fact that Web pages are still inherently stateless. This means that when you move from page to page, you tend to lose the data that the pages use. Although this is not a big problem when you are creating simple Web pages that perform easy tasks, when you begin creating real applications, especially dealing with databases or data that users input, this factor can be a big hassle. State Management on the Client In the past, the statelessness of Web pages was dealt with to an extent in a number of ways on the client side: • Cookies. Small files that a Web application creates. Cookies store data on the local machines of those who are accessing the Web application. A couple of problems exist with just using cookies. First, cookies are stored on the local machine, so the machine (or browser) must allow them. Second, the type of data that can be stored in cookies is limited. • Query strings. Information that is appended to the end of a page's URL. You will see examples of this when you're creating hyperlinks and calling new Web pages. • Hidden fields. An HTML field that is hidden to the user. These are not visible to the class module either. • Control.ViewState property. Provides a dictionary object for retaining values between multiple requests for the same page. Note that this is the method that the page uses to preserve page and control property values between round trips. Although some of these management techniques have been used in ASP, they are still valid in .NET, and they are useful given the correct circumstances. When you're developing in ASP.NET, some additional solutions are available for state management. Those solutions are handled on the server side. Server-Side Solution to State Management Depending on the information that you want to retain, .NET has a number of ways to handle state management. Although you could use the methods just mentioned, a few other options are available as well: • Application state. You can save values to this object Application("ItemName") = value by using an instance of the HttpApplicationState class, but all those people who are in the application at that time will be able to see it. • Session state. This option allows you to maintain state for the individual session. This is discussed further in the next section. • Database support. SQL Server helps you to maintain state by adding values to the Temp database on the server. Using the Session Object The Session object is pretty straightforward to work with. When you assign the variable, you will use the following syntax: Session("SessionVariableName") = Value SessionVariableName is in fact used inside the quotes. It can be whatever you want to call it. Value can be any type of variable, including a DataTable object, as you will see in the steps that follow. Sometimes, you can stash the data table and a Boolean variable to the Session object. Following is one of the lines of code that stores the data table: Session("MyLookupData") = mdtLookupData MyLookupData is the name of the entry that is created in the Session object. mdtLookupData is the variable name of the DataTable object, declared at the module level. When you're reading a variable, you will turn the statement around and add a CType() function to convert the value to the desired type. Variable = CType(Session("SessionVariableName",Type) In the instance of a data table, such as the one used in this How-To, you would see something like this: mdtLookupData = CType(Session("MyLookupData"), DataTable) Note that you can use other conversion functions besides CType(). If you don't convert the value, then the Object type will be returned. Another task that is necessary to perform is testing whether the entry in the Session object has been made. You do this by testing the Session entry against the Nothing keyword, as seen here: 'Put user code to initialize the page here If Not (Session("MyLookupData") Is Nothing) Then mdtLookupData = CType(Session("MyLookupData"), DataTable) End If This code is used in the Load event of the page. If the entry has been created in the Session object, then the data is loaded into the variable. You can also use the opposite as well. If the entry in the Session object is Nothing, then create the entry. This is just a quick and simple way of taking advantage of the Session object. There are probably hundreds of other ways to take advantage of the Session object. For more information on this, check out Session State in the .NET Framework Developer's Guide, which is part of the help provided by Visual Studio. Type in "state management in ASP.NET" for the index to locate the Session object topic. You can find all of the examples in this chapter in the Solution called Visual Basic .NET- Chapter 5 on the Web site. . Dealing with Stateless Programming One of the big differences lies in the fact that Web pages are still inherently stateless. This means. especially dealing with databases or data that users input, this factor can be a big hassle. State Management on the Client In the past, the statelessness