ASP.NET

Reading CSV and Bind to GridView

2010-09-03T01:59:00.000-07:00


public DataSet readCsv()
{
try
{
string strPath = @"Path of the file";
string ConnectionString =
string.Format(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};
Extended Properties=""text;HDR=Yes;FMT=Delimited"";"
, strPath);
string CommandText = string.Format(@"SELECT * FROM Nameofthefile.csv", ConnectionString);
DataSet CSVDataSet = new DataSet();
OleDbConnection CSVConnection = new OleDbConnection(ConnectionString);
OleDbDataAdapter CSVAdapter = new OleDbDataAdapter(CommandText, CSVConnection);
CSVConnection.Open();
CSVAdapter.Fill(CSVDataSet, "FileName.csv");
CSVConnection.Close();
GVcsv.DataSource = CSVDataSet;
GVcsv.DataBind();
return CSVDataSet;
}
catch (Exception ex)
{
lblerror.Text = ex.Message;
throw ex;
}

}

Integer validation

2008-06-17T11:03:00.000-07:00

here field is textbox where user enters value

function val3(field)
{
var valid = "0123456789"
var ok = "yes";
var temp;
for (var i=0; i{
temp = "" + field.value.substring(i, i+1);
if (valid.indexOf(temp) == "-1")
ok = "no";
}
if (ok == "no")
{
alert("Invalid entry! Only numbers are accepted!");
}
}

Email Validation

2008-06-17T11:00:00.000-07:00

Here str is textbox where user enters email id


<script language="javascript">

function echeck(str) 
{
  var at="@"
  var dot="."
  var lat=str.indexOf(at)
  var lstr=str.length
  var ldot=str.indexOf(dot)
  if (str.indexOf(at)==-1)
  {
     alert("Invalid E-mail ID")
     return false
  }

  if (str.indexOf(at)==-1 || str.indexOf(at)==0 || str.indexOf(at)==lstr)
  {
     alert("Invalid E-mail ID")
     return false
  }

 if (str.indexOf(dot)==-1 || str.indexOf(dot)==0 || str.indexOf(dot)==(lstr-1))
  {
      alert("Invalid E-mail ID")
      return false
  }
   if (str.indexOf(at,(lat+1))!=-1)
   {
      alert("Invalid E-mail ID")
      return false
   }
   if (str.substring(lat-1,lat)==dot || str.substring(lat+1,lat+2)==dot)
   {
      alert("Invalid E-mail ID")
      return false
   }
   if (str.indexOf(dot,(lat+2))==-1)
   {
      alert("Invalid E-mail ID")
      return false
   }
   if (str.indexOf(" ")!=-1)
   {
      alert("Invalid E-mail ID")
      return false
   } 
}
</script>

xml-11

2008-02-13T03:18:00.000-08:00

copy1)Explain what a DiffGram is, and a good use for one?
Answer : A DiffGram is an XML format that is used to identify current and original versions of data elements. When sending and retrieving a DataSet from an XML Web service, the DiffGram format is implicitly used.
The DataSet uses the DiffGram format to load and persist its contents, and to serialize its contents for transport across a network connection. When a DataSet is written as a DiffGram, it populates the DiffGram with all the necessary information to accurately recreate the contents, though not the schema, of the DataSet, including column values from both the Original and Current row versions, row error information, and row order.
DiffGram Format
The DiffGram format is divided into three sections: the current data, the original (or “before”) data, and an errors section, as shown in the following example.

xmlns:msdata=”urn:schemas-microsoft-com:xml-msdata”
xmlns:diffgr=”urn:schemas-microsoft-com:xml-diffgram-v1?
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

The DiffGram format consists of the following blocks of data:

The name of this element, DataInstance, is used for explanation purposes in this documentation. A DataInstance element represents a DataSet or a row of a DataTable. Instead of DataInstance, the element would contain the name of the DataSet or DataTable. This block of the DiffGram format contains the current data, whether it has been modified or not. An element, or row, that has been modified is identified with the diffgr:hasChanges annotation.

This block of the DiffGram format contains the original version of a row. Elements in this block are matched to elements in the DataInstance block using the diffgr:id annotation.
This block of the DiffGram format contains error information for a particular row in the DataInstance block. Elements in this block are matched to elements in the DataInstance block using the diffgr:id annotation.

Tracing Overview-3

2007-12-25T01:30:00.000-08:00

Tracing Overview

To enable tracing for a page, include the following directive at the top of the page code:

Trace statements can also be organized by category, using the TraceMode attribute of the Page directive. If no TraceMode attribute is defined, the default value is SortByTime.

• Page-level Tracing: At the page level, developers can use the TraceContext instrinsic to write custom debugging statements that appear at the end of the client output delivered to the requesting browser. ASP.NET also inserts some helpful statements regarding the start/end of lifecycle methods, like Init, Render, and PreRender, in addition to the inputs and outputs to a page, such as form and QueryString variables or headers, and important statistics about the page's execution (control hierarchy, session state, and application state). Because tracing can be explicitly enabled or disabled for a page, these statements can be left in the production code for a page with no impact to the page's performance. Each statement can be associated with a user-defined category for organizational purposes, and timing information is automatically collected by the ASP.NET runtime. The resulting output can be ordered by either time or category.

• Application-level Tracing: Application-level tracing provides a view of several requests to an application's pages at once. Like page-level tracing, it also displays inputs and outputs to a page, such as form and QueryString variables or headers, as well as some important statistics (control hierarchy, session state, and application state). Application-level tracing is enabled through the ASP.NET configuration system, and accessed as a special mapped URL into that application (Trace.axd). When application tracing is enabled, page-level tracing is automatically enabled for all pages in that application (provided there is no page-level directive to explicitly disable trace).

Application-level Trace Logging
The attributes supported in the trace configuration section are listed in the table below:

Value ...............................................................................Description

enabled ...........................................................................Set to true false, indicates whether Tracing is enabled for the application (default is false)

pageOutput .....................................................................Set to true false, indicates whether trace information should be rendered at the end of each page - or only accessible via the trace.axd utility (default is false)

requestLimit ..................................................................Number of trace requests to store on the server (default is 10)

traceMode .....................................................................Set to SortByTime SortByCategory, indicates the display order for Trace messages (default is SortByTime)

localOnly .......................................................................Set to true false, indicates whether Tracing is enabled for localhost users or for all users (default is true)

Configuration File Format

2007-12-25T01:29:00.000-08:00

Configuration File Format
ASP.NET configuration files are XML-based text files--each named web.config--that can appear in any directory on an ASP.NET Web application server. Each web.config file applies configuration settings to the directory it is located in and to all virtual child directories beneath it. Settings in child directories can optionally override or modify settings specified in parent directories. The root configuration file--WinNT\Microsoft.NET\Framework\\config\machine.config--provides default configuration settings for the entire machine. ASP.NET configures IIS to prevent direct browser access to web.config files to ensure that their values cannot become public (attempts to access them will cause ASP.NET to return 403: Access Forbidden).

If a web.config file is present at the root directory for a site, for example "Inetpub\wwwroot", its configuration settings will apply to every application in that site. Note that the presence of a web.config file within a given directory or application root is completely optional. If a web.config file is not present, all configuration settings for the directory are automatically inherited from the parent directory.

Configuration Section Handlers and Sections
A web.config file is an XML-based text file that can contain standard XML document elements, including well-formed tags, comments, text, cdata, and so on. The file may be ANSI, UTF-8, or Unicode; the system automatically detects the encoding. The root element of a web.config file is always a tag. ASP.NET and end-user settings are then encapsulated within the tag, as follows:

The tag typically contains three different types of elements:
1) Configuration section handler declarations
2) Configuration section groups and
3) Configuration section settings

Authentication

2007-12-24T15:11:00.000-08:00

1. ASP.NET Authentication Providers and IIS Security
ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:

Forms Authentication: Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.

Passport Authentication: This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.

Windows Authentication: This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
// web.config file

Web Service-1

2007-12-24T11:55:00.000-08:00

Web Service Questions

What is the transport protocol you use to call a Web service?
SOAP (Simple Object Access Protocol) is the preferred protocol.

True or False: A Web service can only be written in .NET?
False

What does WSDL stand for?
Web Services Description Language.

Where on the Internet would you look for Web services?
http://www.uddi.org

True or False: To test a Web service you must create a Windows application or Web application to consume this service?
False, the web service comes with a test page and it provides HTTP-GET method to test.

PageEvents-2

2007-12-24T11:36:00.000-08:00

Initialization

The first method that executes when a page is requested is always the constructor. You can initialize many of the custom properties or objects in the page at this time, although there are a few limitations since the page hasn't fully initialized yet. In particular, you will have to use the HttpContext.Current object to access the Request QueryString, Form, and Cookies collections, along with the Cache object. However, there is no way to access the Session collection within the constructor.
The next method that executes is the AddParsedSubObject method, which actually adds all the individual controls that make up a page into the control collection tree. This method is typically overridden by some of the advanced page template solutions in order to add the page contents into a particular control in the page template. This method is recursively called on all children controls for each page control, and each of these controls is initialized at this time, starting with the innermost.

The next method that executes is the DeterminePostBackMode method of the page class. This method allows you to affect the value of IsPostBack and all the related events, which might be useful if you need to load ViewState from a database for a redirect, since we will see that ViewState is only restored when IsPostBack is actually true. Just return null to force non-PostBack and return Request.Form to force a PostBack. This is not recommended, except in special cases, since it affects other events too.

The page's OnInit method is executed next, which is typically the first method used. By the time this occurs, all the controls defined in your page will be initialized, which means that all the original values specified in the aspx page will be applied. However, ViewState and any posted values will not have been applied to controls yet, so anything that changed as a result of the code or user will not yet be restored. This is usually the best place to create, and recreate, any dynamic controls used.

Restore and Load

The next method, LoadPageStateFromPersistenceMedium, only executes for PostBacks. This method is overridden when you have altered how the page's ViewState was saved, later in the SavePageStateToPersistenceMedium, when using Session or Custom Stores. The default implementation assumes ViewState is a Base64 encoded hidden form field, but this can be changed in these two methods using code found in this related article. Note that this method does not actually restore ViewState to the page or its controls.
After ViewState is retrieved, the next method, LoadViewState, restores it to the page, and then recursively to each control and their children, but again only on PostBacks. After this executes, each control will now be restored to the state it was last time, but user posted values will still not be applied, since this is not part of ViewState. The best use of this method is to restore any dynamic controls you created in events, based on values you must manually save in ViewState, which is now available to use.

The next method, ProcessPostData, only executes for PostBacks, and it is not able to be overridden, since it is a private method implemented by the base page class. This method finally restores the user's posted form values by matching up controls with the names of the values, which means your page will finally be fully restored. The only catch is that dynamic controls must be created prior to this page method. This is also the method that records changes in values for the changed events later.

The page's OnLoad method is executed next, which is typically used for most code, since this is the first place in the page lifecycle that all values are restored. Most code checks the value of IsPostBack to avoid unnecessarily resetting state. You may also wish to call Validate and check the value of IsValid in this method. You can also create dynamic controls in this method, and all the control's methods will be executed to catch up, including ViewState, but posted values would not be.

Raised Events

The next method, ProcessPostData, is actually a second pass of the earlier method, which still only executes for PostBacks and is not overridable since private method. This second pass always seems a little odd when you first notice it in the page trace, but it occurs because dynamic controls recreated in OnLoad need their posted values. Any controls that are dynamically created after this method, while having ViewState restored, will not get their posted values nor be able to trigger any changed events.
The next method, RaiseChangedEvents, also occurs only for PostBacks, and it too is a private method that is implemented in the base page class that cannot be overridden. This is the time in the page lifecycle that the changed events are actually raised, based on the differences that ProcessPostData noted before and after posted values. You may also want to call Validate and check the value of IsValid, if not already. There is no guarantee about the order that multiple changed events will be raised.

The next method, RaisePostBackEvent, also occurs only for PostBacks, and it too is a private method that is implemented in the base page class that cannot be overridden. This is where the event that actually submitted the form, unless using AutoPostBack, is actually raised, typically a button, or a control that uses javascript to submit. If not manually called already, Validate is also called, when using some Validators. Note a bug in IE sometimes allows the Enter key to submit without triggering an event.

The page's OnPreRender method is executed next, which is typically the last chance to affect the page and its controls before it is rendered to the client's browser. You can also create dynamic controls in this method, and all the control's methods will be executed to catch up, including ViewState, but the earlier private methods will not receive another pass, meaning no posted values are restored and no events. This is a good place to catch a PostBack without an event due to the bug noted in IE.

Save and Render

The next method that executes, regardless whether PostBack or not, is SaveViewState which recursively runs for each control and their children, to create the ViewState. ViewState basically stores any property values that are different from the original values that are defined in the aspx page, whether changed in the code or by the user. Note that control values are saved according to their location in the control tree, so ViewState can get corrupted if dynamic controls are later added in wrong positions.
The next method, SavePageStateToPersistenceMedium, actually saves the page ViewState. This method is overridden, along with LoadPageStateFromPersistenceMedium, to save the ViewState either to Session or a Custom Store, instead of using the hidden field. This is useful for low bandwidth cases, and Session is the default for Mobile Pages. See the code found in this related article for details of using these two methods, and note that a bug in ASP.NET requires a __VIEWSTATE field to be sent, even if empty.

The page's Render method is executed next, which recursively runs for each control and their children, to actually create and send the resulting html to the browser. This method is used in some page template solutions to add common headers and footers to the page without using server controls, which always have a little extra overhead. Note that changes made here must be pure html, since controls are done at this time. You can capture the html output using StringBuilder, StringWriter, and HtmlTextWriter.

The very last method to be executed is OnUnload, which also calls the Dispose method. This method gives you a chance to cleanup any unmanaged resources used in the page, typically things like closing any open files or database connections open earlier. Note that this method runs only after the page has been sent to the client's browser, so it will only affect server objects, and it will not show up in a trace of the page. And that's the page lifecycle -- everything runs all over again with each new request.

Listing 1: Page Events Summary

--------------------------------------------------------------------------------

Method . . .. . PostBack . . . . . Controls

--------------------------------------------------------------------------------

Constructor . . . . . Always . . . . . All
AddParsedSubObject . . . . . Always . . . . . All
DeterminePostBackMode . . . . . Always . . . . . Page
OnInit Always All

--------------------------------------------------------------------------------

LoadPageStateFromPersistenceMedium . . . . . PostBack . . . . . Page
LoadViewState . . . . . PostBack . . . . . All
ProcessPostData1 . . . . . PostBack . . . . . Page
OnLoad . . . . . Always . . . . . All

--------------------------------------------------------------------------------

ProcessPostData2 . . . . . PostBack . . . . . Page
RaiseChangedEvents . . . . . PostBack . . . . . Page
RaisePostBackEvent . . . . . PostBack . . . . . Page
OnPreRender . . . . . Always . . . . . All

--------------------------------------------------------------------------------

SaveViewState . . . . . Always . . . . . All
SavePageStateToPersistenceMedium . . . . . Always . . . . . Page
Render . . . . . Always . . . . . All
OnUnload . . . . . Always . . . . . All

--------------------------------------------------------------------------------

PageEvents

2007-12-24T11:10:00.000-08:00

What is the role of the ASP.NET worker process?
What is aspnet_wp.exe?

For faster execution of ASP.NET applications, that are primarily based to be hosted on IIS servers, the aspnet_wp.exe comes into picture. This file (aspnet_wp.exe) is actually the ASP.NET worker process. The worker process is introduced to actually share the load on the IIS, so that application domains and other services may be maintained by a single worker process.

The aspnet_wp.exe worker process is a part of the Microsoft ASP.NET framework, and it is responsible for most of the technical processes in the ASP.NET framework. There may be multiple instances of ASP.NET worker process running on IIS 6 (a process running as inetinfo.exe), depending on multiple application pools. The worker process handles all the requests passed to the ASP.NET framework, so we may say that its actually the main engine that handles all requests pertaining to ASPNET. For example, when a request for an .aspx page is recieved by the IIS server, the dll called aspnet_isapi.dll passes this request to the aspnet_wp.exe worker process.

Explain the page life cycle in ASP.NET 2.0

ASP.NET 2.0 Page Life Cycle - The lifetime of an ASP.NET page is filled with events. A series of processing steps takes place during this page life cycle. Following tasks are performed:

* Initialization
* Instantiation of controls
* Restoration & Maintainance of State
* Running Event Handlers
* Rendering of data to the browser

The life cycle may be broken down into Stages and Events. The stages reflect the broad spectrum of tasks performed. The following stages take place

1) Page Request - This is the first stage, before the page life cycle starts. Whenever a page is requested, ASP.NET detects whether the page is to be requested, parsed and compiled or whether the page can be cached from the system.

2) Start - In this stage, properties such as Request and Response are set. Its also determined at this stage whether the request is a new request or old, and thus it sets the IsPostBack property in the Start stage of the page life cycle.

3) Page Initialization - Each control of the page is assigned a unique identification ID. If there are themes, they are applied. Note that during the Page Initialization stage, neither postback data is loaded, nor any viewstate data is retrieved.

4) Load - If current request is a postback, then control values are retrieved from their viewstate.

5) Validation - The validate method of the validation controls is invoked. This sets the IsValid property of the validation control.

6) PostBack Event Handling - Event handlers are invoked, in case the request is a postback.

7) Rendering - Viewstate for the page is saved. Then render method for each control is called. A textwriter writes the output of the rendering stage to the output stream of the page's Response property.

8) Unload - This is the last stage in the page life cycle stages. It is invoked when the page is completely rendered. Page properties like Respone and Request are unloaded.

Note that each stage has its own events within it. These events may be used by developers to handle their code. Listed below are page events that are used more frequently.

PreInit - Checks the IsPostBack property. To create or recreate dynamic controls. To set master pages dynamically. Gets and Sets profile propety values.

Init - Raised after all controls are initialized, and skin properties are set.

InitComplete - This event may be used, when we need to be sure that all initialization tasks are complete.

PreLoad - If processing on a control or a page is required before the Load event.

Load - invokes the OnLoad event on the page. The same is done for each child control on the page. May set properties of controls, create database connections.

Control Events - These are the control specific events, such as button clicks, listbox item selects etc.

LoadComplete - To execute tasks that require that the complete page has been loaded.

PreRender - Some methods are called before the PreRenderEvent takes place, like

EnsureChildControls- data bound controls that have a dataSourceId set also call the DataBind method.

Each control of the page has a PreRender event. Developers may use the prerender event to make final changes to the controls before it is rendered to the page.

SaveStateComplete - ViewState is saved before this event occurs. However, if any changes to the viewstate of a control is made, then this is the event to be used. It cannot be used to make changes to other properties of a control.

Render - This is a stage, not an event. The page object invokes this stage on each control of the page. This actually means that the ASP.NET server control's HTML markup is sent to the browser.

Unload - This event occurs for each control. It takes care of cleanup activities like wiping the database connectivities.

Cookies

2007-12-24T11:08:00.000-08:00

What is a cookie? Limitations of cookie? Permanent cookie?

Cookie - A cookie is a piece of data that is stored on a user's browser. Thus, a cookie does not use any server memory. It is actually a small text file which is created by the broswer on the hard disk of the user. It is actually a piece of information in the form of text strings. A web server sends a cookie to a user (client browser) and then the browser stores it. A cookie is used to store information of a user & information about a user's preferences. How does the cookie works? - When a user visits a site, say www.amazon.com, and creates a profile out there, the server sends an ID (basically an ID to track this user) and saves the ID through the user's browser in the form of a cookie on the user's system. When the user revisits this site, the website tracks the user's system for the existence of any cookie, and in case it finds a cookie, it customizes the site based on the user's settings and preferences. Now lets talk about how to create a cookie in ASP.NET. It is pretty simple. There is a class in the System.Web namespace by the name HttpCookie. This class may be used to easily create a cookie on the user's system. Below is a code sample on how to use a cookie in ASP.NET ...

//Creating a cookie

HttpCookie sampleCookie = new HttpCookie("UserColorSetting");
sampleCookie.Values.Add("Background", txtBackgroundColor.Text);
sampleCookie.Expires = #12/31/2010#;
Response.Cookies.Add(sampleCookie);

//Getting a cookie value from the user's computer
String sGetCookie;
sGetCookie = Request.Cookies("UserColorSetting")("Background").ToString();

Limitations of Cookies - Cookies are meant for infrequent storage of small pieces of information. They are not meant as a normal communication or mechanism. Note that web browsers are not required to save more than 300 cookies total, nor more than 20 cookies per web server (for the entire server, not just for the page or site on the server), nor to retain more than 4 kilobytes of data per cookie (both name and value count towards this 4 kilobyte limit). The biggest limitation of these is the 20 cookies per server limit, and so it is not a good idea to use a different cookie for each variable that has to be saved. Rather save a single cookie containing a lot of information.

How to store global variables?,application,cache,session

2007-12-24T11:03:00.000-08:00

Global variables should always be used with caution. They are the best means of storing data that has to be accessed anywhere. The most common ways of accessing global variables in ASP.NET are by using Application, Cache, and Session objects.Application - Application objects are application level global variables, that need to be shared for all user sessions. Thus, data specific to a user should'nt be saved in application objects. While using application objects, the objects are locked so that multiple page requests cannot access a specific application object. Below is a code example for usage of application object...

Application.Lock();
Application("UserData") = "dotnetuncle";
Application.UnLock();
Response.Redirect("DestinationPage.aspx");
//DestinationPage.aspx gets the value from the Application State
String sString = Application("UserData").ToString();

Cache - The cache object is similar to the application object in scope, however, it does not need any explicit locking and unlocking. Code below shows usage of Cache object...

Cache("Userdata") = "dotnetuncle";
Response.Redirect("DestinationPage.aspx");
//Destination.aspx retrieves the value from Cache object
String sString = Cache("Userdate").ToString();

The cache object also shares data across all user sessions. The cache object has features like it can automatically expire cached content after specified time periods or once memory consumption has reached a maximum.Session - The session object is used to store the data specific to a user for the entire length of a user's visit to a website. Below is a code that shows usage of the session object in ASP.NET ...

//InitialPage.aspx stores the user’s credentials in Session state

Session("UserName") = txtUserName.Text;
Server.Transfer("DestinationPage.aspx");

//DestinationPage.aspx gets the user’s name from Session state
String sString = Session("UserName").ToString();

ASP.NET stores session values in the server memory. If there are plenty of active user's of a website, then the memory consumption on the server increases by leaps. Because of this reason, large websites use very less Session Variables. Session state can be configured to be automatically stored in a SQL Server database, or it can be configured to be stored centrally in a state server within a server farm. By default, a user’s session ends 20 minutes after their last page request and their data goes out of scope, freeing it from memory. In case user information is to be tracked by a large website, then a cookie is preferred.

Querry String:

2007-12-24T10:52:00.000-08:00

There are several methods to pass values from one page to another page. Described below are few methods to pass values between pages:QueryString - The QueryString method of passing values between web pages is one of the oldest methods of passing values between pages. A variable value is properly encoded before it is placed on a querystring. This is to make sure that characters that cause problems (like symbols and spaces) are encoded correctly. See the code below to see how QueryString functionality works.

//Code in InitialPage.aspxString sString;sString = Server.UrlEncode("string in InitialPage.aspx");Response.Redirect("DestinationPage.aspx?Value=" & sString);
//Code in DestinationPage.aspx reads the QueryStringString sString;sString = Request.QueryString("Value");Response.Write("Your name is " & sString);The data in the DestinationPage.aspx in the URL looks like this...

//http://www.somepage.com/Destinationpage.aspx?value=initialvalue

Context - The context object is used to send values between pages. Its similar to the session object, the difference being that, the Context object goes out of scope when the page is sent to a browser. Example code below shows how to use Context object.

'InitialPage.aspx stores value in context before sending it
Context.Items("MyData") = "initialvalue";
Server.Transfer("DestinationPage.aspx");'DestinationPage.aspx retrieves the value from InitialPage.aspx's contextString sString;sString = Context.Items("MyDate").ToString;Response.Write("The data is as follows: " & sString);

Session - The session object is used to persist data across a user session during the user's visit to a website. It is almost same as the Context object. When we use Response.Redirect, it causes the Context object to go away, so rather the Session object is used in such a scenario. Session object uses more of server memory than a context object. Example code below shows how to use Session object.

'InitialPage.aspx stores value in session before sending itSession.Items("MyData") = "initialvalue";
Response.Redirect("DestinationPage.aspx");

'DestinationPage.aspx retrieves the value from InitialPage.aspx's session

String sString;sString = Session.Items("MyDate").ToString;

Response.Write("The data is as follows: " & sString);
You may notice above, I have used Response.Redirect with session object, and server.transfer with a context object.

State Management

2007-12-24T06:48:00.000-08:00

State Management Questions

What is ViewState?
ViewState allows the state of objects (serializable) to be stored in a hidden field on the page. ViewState is transported to the client and back to the server, and is not stored on the server or any other external source. ViewState is used the retain the state of server-side objects between postabacks.
What is the lifespan for items stored in ViewState?
Item stored in ViewState exist for the life of the current page. This includes postbacks (to the same page).
What does the "EnableViewState" property do? Why would I want it on or off?
It allows the page to save the users input on a form across postbacks. It saves the server-side values for a given control into ViewState, which is stored as a hidden value on the page before sending the page to the clients browser. When the page is posted back to the server the server control is recreated with the state stored in viewstate.
What are the different types of Session state management options available with ASP.NET?
ASP.NET provides In-Process and Out-of-Process state management. In-Process stores the session in memory on the web server. This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server. Out-of-Process Session state management stores data in an external data source. The external data source may be either a SQL Server or a State Server service. Out-of-Process state management requires that all objects stored in session are serializable