Docstoc

Jitendra asp.net

Document Sample
Jitendra asp.net Powered By Docstoc
					    Jitendra.Net Notes
   Entries (RSS)

   Comments (RSS)

   Home
   .Net Framework
   Ado.Net
   Asp.Net
   C# .net
   C# Notes
   Java Script
   Project 2011


    Asp.Net
    ASP.NET State Management Overview
    A new instance of the Web page class is created each time the page is posted to the server. In traditional Web
    programmin
    g, this would typically mean that all information associated with the page and the controls on the page would be lost with
    each round trip. For example, if a user enters information into a text box, that information would be lost in the round trip
    from the browser or client device to the server.
    To overcome this inherent limitation of traditional Web programming, ASP.NET includes several options that help you
    preserve data on both a per-page basis and an application-wide basis. These features are as follows:




   View state
   Control state
   Hidden fields
   Cookies
   Query strings
   Application state
   Session state
   Profile Properties
    View state, control state, hidden fields, cookies, and query strings all involve storing data on the client in various ways.
    However, application state, session state, and profile properties all store data in memory on the server. Each option has
    distinct advantages and disadvantages, depending on the scenario.
    Client-Based State Management Options
    The following sections describe options for state management that involve storing information either in the page or on the
    client computer. For these options, no information is maintained on the server between round trips.View
    StateThe ViewState property provides a dictionary object for retaining values between multiple requests for the same
    page. This is the default method that the page uses to preserve page and control property values between round
    trips.When the page is processed, the current state of the page and controls is hashed into a string and saved in the page
    as a hidden field, or multiple hidden fields if the amount of data stored in the ViewState property exceeds the specified
    value in the MaxPageStateFieldLength property. When the page is posted back to the server, the page parses the view-
    state string at page initialization and restores property information in the page.You can store values in view state as well.
    For more information on using View State, see ASP.NET View State Overview. For recommendations about when you
    should use view state, see ASP.NET State Management Recommendations.Control StateSometimes you need to store
    control-state data in order for a control to work properly. For example, if you have written a custom control that has
    different tabs that show different information, in order for that control to work as expected, the control needs to know
    which tab is selected between round trips. The ViewState property can be used for this purpose, but view state can be
    turned off at a page level by developers, effectively breaking your control. To solve this, the ASP.NET page framework
    exposes a feature in ASP.NET called control state.The ControlState property allows you to persist property information that
    is specific to a control and cannot be turned off like theViewState property.
    Hidden Fields
    ASP.NET allows you to store information in a HiddenField control, which renders as a standard HTML hidden field. A hidden
    field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a
page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of
other controls. A hidden field acts as a repository for any page-specific information that you want to store directly in the
page.
 Security Note
It is easy for a malicious user to see and modify the contents of a hidden field. Do not store any
information in a hidden field that is sensitive or that your application relies on to work properly.
For more information, seeASP.NET State Management Recommendations.
A HiddenField control stores a single variable in its Value property and must be explicitly added to the page. For more
information, see HiddenField Web Server Control Overview.
In order for hidden-field values to be available during page processing, you must submit the page using an HTTP POST
command. If you use hidden fields and a page is processed in response to a link or an HTTP GET command, the hidden
fields will not be available. For usage recommendations, see ASP.NET State Management Recommendations.
Cookies
A cookie is a small amount of data that is stored either in a text file on the client file system or in-memory in the client
browser session. It contains site-specific information that the server sends to the client along with page output. Cookies
can be temporary (with specific expiration times and dates) or persistent.
You can use cookies to store information about a particular client, session, or application. The cookies are saved on the
client device, and when the browser requests a page, the client sends the information in the cookie along with the request
information. The server can read the cookie and extract its value. A typical use is to store a token (perhaps encrypted)
indicating that the user has already been authenticated in your application.



 Security Note
The browser can only send the data back to the server that originally created the cookie.
However, malicious users have ways to access cookies and read their contents. It is
recommended that you do not store sensitive information, such as a user name or password, in a
cookie. Instead, store a token in the cookie that identifies the user, and then use the token to look
up the sensitive information on the server.
For more information about using cookies, see Cookies and ASP.NET State Management Recommendations.
Query Strings
A query string is information that is appended to the end of a page URL. A typical query string might look like the following
example:
Copy
http://www.contoso.com/listwidgets.aspx?category=basic&price=100
In the URL path above, the query string starts with a question mark (?) and includes two attribute/value pairs, one called
“category” and the other called “price.”
Query strings provide a simple but limited way to maintain state information. For example, they are an easy way to pass
information from one page to another, such as passing a product number from one page to another page where it will be
processed. However, some browsers and client devices impose a 2083-character limit on the length of the URL.
 Security Note
Information that is passed in a query string can be tampered with by a malicious user. Do not
rely on query strings to convey important or sensitive data. Additionally, a user can bookmark
the URL or send the URL to other users, thereby passing that information along with it. For more
information, see ASP.NET State Management Recommendations and How to: Protect Against
Script Exploits in a Web Application by Applying HTML Encoding to Strings.
In order for query string values to be available during page processing, you must submit the page using an HTTP GET
command. That is, you cannot take advantage of a query string if a page is processed in response to an HTTP POST
command. For usage recommendations, see ASP.NET State Management Recommendations.
Server-Based State Management Options

Once you add your application-specific information to application state, the server manages it. For usage
recommendations, see ASP.NET State Management Recommendations.
Session State
ASP.NET allows you to save values by using session state — which is an instance of the HttpSessionState class — for each
active Web-application session. For an overview, see ASP.NET Session State Overview.
Session state is similar to application state, except that it is scoped to the current browser session. If different users are
using your application, each user session will have a different session state. In addition, if a user leaves your application
and then returns later, the second user session will have a different session state from the first.
Session state is structured as a key/value dictionary for storing session-specific information that needs to be maintained
between server round trips and between requests for pages. For more information, see ASP.NET Session State Overview.
    You can use session state to accomplish the following tasks:
   Uniquely identify browser or client-device requests and map them to an individual session instance on the server.
   Store session-specific data on the server for use across multiple browser or client-device requests within the same session.
   Raise appropriate session management events. In addition, you can write application code leveraging these events.
    Once you add your application-specific information to session state, the server manages this object. Depending on which
    options you specify, session information can be stored in cookies, on an out-of-process server, or on a computer running
    Microsoft SQL Server. For usage recommendations, see ASP.NET State Management Recommendations.
    Profile Properties
    ASP.NET provides a feature called profile properties, which allows you to store user-specific data. This feature is similar to
    session state, except that the profile data is not lost when a user‘s session expires. The profile-properties feature uses an
    ASP.NET profile, which is stored in a persistent format and associated with an individual user. The ASP.NET profile allows
    you to easily manage user information without requiring you to create and maintain your own database. In addition, the
    profile makes the user information available using a strongly typed API that you can access from anywhere in your
    application. You can store objects of any type in the profile. The ASP.NET profile feature provides a generic storage system
    that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.
    To use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you
    to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a
    custom format and to a custom storage mechanism such as an XML file, or even to a web service.
    Because data that is placed in profile properties is not stored in application memory, it is preserved through Internet
    Information Services (IIS) restarts and worker-process restarts without losing data. Additionally, profile properties can be
    persisted across multiple processes such as in a Web farm or a Web garden. For more information, see ASP.NET Profile
    Properties Overview.
    ASP.NET State Management Recommendations
    State management is the process by which you maintain state and page information over multiple requests for the same or
    different pages. As is true for any HTTP-based technology, Web Forms pages are stateless, which means that they do not
    automatically indicate whether the requests in a sequence are all from the same client or even whether a single browser
    instance is still actively viewing a page or site. Furthermore, pages are destroyed and re-created with each round trip to
    the server; therefore, page information will not exist beyond the life cycle of a single page. For more information about
    server round trips and the life cycle of Web Forms pages, see ASP.NET Page Life Cycle Overview.
    ASP.NET provides multiple ways to maintain state between server round trips. Which of these options you choose depends
    heavily upon your application, and it should be based on the following criteria:
   How much information do you need to store?
   Does the client accept persistent or in-memory cookies?
   Do you want to store the information on the client or on the server?
   Is the information sensitive?
   What performance and bandwidth criteria do you have for your application?
   What are the capabilities of the browsers and devices that you are targeting?
   Do you need to store information per user?
   How long do you need to store the information?
   Do you have a Web farm (multiple servers), a Web garden (multiple processes on one machine), or a single process that
    serves the application?
    Client-Side State Management Options
    Storing page information using client-side options doesn‟t use server resources. These options typically have minimal
    security but fast server performance because the demand on server resources is modest. However, because you must
    send information to the client for it to be stored, there is a practical limit on how much information you can store this
    way.The following are the client-side state management options that ASP.NET supports:
   View state
   Control state
   Hidden fields
   Cookies
   Query strings
    View State
    Web Forms pages provide the ViewState property as a built-in structure for automatically retaining values between
    multiple requests for the same page. View state is maintained as a hidden field in the page. For more information,
    see ASP.NET State Management Overview.
    You can use view state to store your own page-specific values across round trips when the page posts back to itself. For
    example, if your application is maintaining user-specific information — that is, information that is used in the page but is
    not necessarily part of any control — you can store it in view state.
    Advantages of using view state are:
   No server resources are required       The view state is contained in a structure within the page code.
   Simple implementation       View state does not require any custom programming to use. It is on by default to maintain
    state data on controls.
   Enhanced security features The values in view state are hashed, compressed, and encoded for Unicode
    implementations, which provides more security than using hidden fields.
    Disadvantages of using view state are:
   Performance considerations Because the view state is stored in the page itself, storing large values can cause the
    page to slow down when users display it and when they post it. This is especially relevant for mobile devices, where
    bandwidth is often a limitation.
   Device limitations    Mobile devices might not have the memory capacity to store a large amount of view-state data.
   Potential security risks The view state is stored in one or more hidden fields on the page. Although view state stores
    data in a hashed format, it can still be tampered with. The information in the hidden field can be seen if the page output
    source is viewed directly, creating a potential security issue. For more information, see ASP.NET Web Application
    Security and Basic Security Practices for Web Applications.
    For more information about using view state, see View State Overview.
    Control State
    The ASP.NET page framework provides the ControlState property as way to store custom control data between server
    trips. For example, if you have written a custom control that has different tabs showing different information, in order for
    that control to work as expected, the control needs to know which tab is selected between round trips. View state can be
    used for this purpose, but developers can turn view state off at the page level, effectively breaking your control. Unlike
    view state, control state cannot be turned off, so it provides a more reliable way to store control-state data.
    Advantages of using control state are:
   No server resources are required         By default, control state is stored in hidden fields on the page.
   Reliability Because control state cannot be turned off like view state, control state is a more reliable method for
    managing the state of controls.
   Versatility Custom adapters can be written to control how and where control-state data is stored.
    Disadvantage of using control state are:
   Some programming is required While the ASP.NET page framework provides a foundation for control state, control
    state is a custom state-persistence mechanism. To fully utilize control state, you must write code to save and load control
    state.
    Hidden Fields
    You can store page-specific information in a hidden field on your page as a way of maintaining the state of your page.
    If you use hidden fields, it is best to store only small amounts of frequently changed data on the client.
     Note
    If you use hidden fields, you must submit your pages to the server using the HTTP POST method
    rather than requesting the page via the page URL (the HTTP GET method).
    Advantages of using hidden fields are:




   No server resources are required         The hidden field is stored and read from the page.
   Widespread support       Almost all browsers and client devices support forms with hidden fields.
   Simple implementation Hidden fields are standard HTML controls that require no complex programming logic.
    Disadvantages of using hidden fields are:
   Potential security risks The hidden field can be tampered with. The information in the hidden field can be seen if the
    page output source is viewed directly, creating a potential security issue. You can manually encrypt and decrypt the
    contents of a hidden field, but doing so requires extra coding and overhead. If security is a concern, consider using a
    server-based state mechanism so that no sensitive information is sent to the client. For more information, see ASP.NET
    Web Application Security and Basic Security Practices for Web Applications.
   Simple storage architecture The hidden field does not support rich data types. Hidden fields offer a single string value
    field in which to place information. To store multiple values, you must implement delimited strings and the code to parse
    those strings. You can manually serialize and de-serialize rich data types to and from hidden fields, respectively. However,
    it requires extra code to do so. If you need to store rich data types on the client, consider using view state instead. View
    state has serialization built-in, and it stores data in hidden fields.
   Performance considerations Because hidden fields are stored in the page itself, storing large values can cause the
    page to slow down when users display it and when they post it.
   Storage limitations If the amount of data in a hidden field becomes very large, some proxies and firewalls will prevent
    access to the page that contains them. Because the maximum amount can vary with different firewall and proxy
    implementations, large hidden fields can be sporadically problematic. If you need to store many items of data, consider
    doing one of the following:
o   Put each item in a separate hidden field.
o   Use view state with view-state chunking turned on, which automatically separates data into multiple hidden fields.
o   Instead of storing data on the client, persist the data on the server. The more data you send to the client, the slower the
    apparent response time of your application will be because the browser will need to download or send more data.
    Cookies
    Cookies are useful for storing small amounts of frequently changed information on the client. The information is sent with
    the request to the server. For details about creating and reading cookies, see ASP.NET Cookies Overview.
    Advantages of using cookies are:
   Configurable expiration rules The cookie can expire when the browser session ends, or it can exist indefinitely on the
    client computer, subject to the expiration rules on the client.
   No server resources are required        The cookie is stored on the client and read by the server after a post.
   Simplicity   The cookie is a lightweight, text-based structure with simple key-value pairs.
   Data persistence Although the durability of the cookie on a client computer is subject to cookie expiration processes on
    the client and user intervention, cookies are generally the most durable form of data persistence on the client.
    Disadvantages of using cookies are:
   Size limitations Most browsers place a 4096-byte limit on the size of a cookie, although support for 8192-byte cookies
    is becoming more common in newer browser and client-device versions.
   User-configured refusal      Some users disable their browser or client device‟s ability to receive cookies, thereby limiting
    this functionality.
   Potential security risks Cookies are subject to tampering. Users can manipulate cookies on their computer, which can
    potentially cause a security risk or cause the application that is dependent on the cookie to fail. Also, although cookies are
    only accessible by the domain that sent them to the client, hackers have historically found ways to access cookies from
    other domains on a user‟s computer. You can manually encrypt and decrypt cookies, but it requires extra coding and can
    affect application performance because of the time that is required for encryption and decryption. For more information,
    see ASP.NET Web Application Security and Basic Security Practices for Web Applications.


     Note
    Cookies are often used for personalization, where content is customized for a known user. In
    most of these cases, identification is the issue rather than authentication. Thus, you can typically
    secure a cookie that is used for identification by storing the user name, account name, or a
    unique user ID (such as a GUID) in the cookie and then using the cookie to access the user
    personalization infrastructure of a site.
    Query Strings
    A query string is information that is appended to the end of a page URL. For more information, see ASP.NET State
    Management Overview.
    You can use a query string to submit data back to your page or to another page through the URL. Query strings provide a
    simple but limited way of maintaining some state information. For example, query strings are an easy way to pass
    information from one page to another, such as passing a product number to another page where it will be processed.
    Advantages of using query strings are:

   No server resources are required        The query string is contained in the HTTP request for a specific URL.
   Widespread support       Almost all browsers and client devices support using query strings to pass values.
   Simple implementation ASP.NET provides full support for the query-string method, including methods of reading query
    strings using the Paramsproperty of the HttpRequest object.
    Disadvantages of using query strings are:
   Potential security risks The information in the query string is directly visible to the user via the browser‟s user
    interface. A user can bookmark the URL or send the URL to other users, thereby passing the information in the query
    string along with it. If you are concerned about any sensitive data in the query string, consider using hidden fields in a
    form that uses POST instead of using query strings. For more information, see ASP.NET Web Application Security and Basic
    Security Practices for Web Applications.
   Limited capacity Some browsers and client devices impose a 2083-character limit on the length of URLs.
    Client-Side Method State Management Summary
    The following table lists the client-side state management options that are available with ASP.NET, and provides
    recommendations about when you should use each option.
    State                Recommended usage
    management
    option
    View state           Use when you need to store small amounts of information for a page that will
                         post back to itself. Using the ViewStateproperty provides functionality with
                         basic security.
    Control state        Use when you need to store small amounts of state information for a control
                         between round trips to the server.
    Hidden fields        Use when you need to store small amounts of information for a page that will
                         post back to itself or to another page, and when security is not an issue.NoteYou
                         can use a hidden field only on pages that are submitted to the server.
    Cookies              Use when you need to store small amounts of information on the client and
                         security is not an issue.
    Query string         Use when you are transferring small amounts of information from one page to
                         another and security is not an issue.NoteYou can use query strings only if you
                         are requesting the same page, or another page via a link.
    Server-Side State Management Options




   Application state
   Session state
   Profile properties
   Database support
    Application State
    ASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific
    information that is visible to the entire application. Application-state variables are, in effect, global variables for an
    ASP.NET application. For more information, see ASP.NET Application State Overview
    You can store your application-specific values in application state, which is then managed by the server. For more
    information, see ASP.NET State Management Overview.
    Data that is shared by multiple sessions and does not change often is the ideal type of data to insert into application-state
    variables.
    Advantages of using application state are:
   Simple implementation       Application state is easy to use, familiar to ASP developers, and consistent with other .NET
    Framework classes.
   Application scope Because application state is accessible to all pages in an application, storing information in application
    state can mean keeping only a single copy of the information (for instance, as opposed to keeping copies of information in
    session state or in individual pages).
    Disadvantages of using application state are:
   Application scope The scope of application state can also be a disadvantage. Variables stored in application state are
    global only to the particular process the application is running in, and each application process can have different values.
    Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-
    farm server configurations.
   Limited durability of data Because global data that is stored in application state is volatile, it will be lost if the Web
    server process containing it is destroyed, such as from a server crash, upgrade, or shutdown.
   Resource requirements Application state requires server memory, which can affect the performance of the server as
    well as the scalability of the application.
    Careful design and implementation of application state can increase Web application performance. For example, placing a
    commonly used, relatively static dataset in application state can increase site performance by reducing the overall number
    of data requests to a database. However, there is a performance trade-off. Application state variables containing large
    blocks of information reduce Web server performance as server load increases. The memory occupied by a variable stored
    in application state is not released until the value is either removed or replaced. Therefore, it is best to use application-
    state variables only with small, infrequently changed datasets. For more information, see ASP.NET Performance Overview.
    Session State
    ASP.NET provides a session state, which is available as theHttpSessionState class, as a method of storing session-specific
    information that is visible only within the session. ASP.NET session state identifies requests from the same browser during
    a limited time window as a session, and provides the ability to persist variable values for the duration of that session. For
    more information, see ASP.NET State Management Overviewand ASP.NET Session State Overview.
    You can store your session-specific values and objects in session state, which is then managed by the server and available
    to the browser or client device. The ideal data to store in session-state variables is short-lived, sensitive data that is
    specific to an individual session.
    Advantages of using session state are:
   Simple implementation       The session-state facility is easy to use, familiar to ASP developers, and consistent with other
    .NET Framework classes.
   Session-specific events     Session management events can be raised and used by your application.
   Data persistence Data placed in session-state variables can be preserved through Internet Information Services (IIS)
    restarts and worker-process restarts without losing session data because the data is stored in another process space.
    Additionally, session-state data can be persisted across multiple processes, such as in a Web farm or a Web garden.
   Platform scalability Session state can be used in both multi-computer and multi-process configurations, therefore
    optimizing scalability scenarios.
   Cookieless support Session state works with browsers that do not support HTTP cookies, although session state is most
    commonly used with cookies to provide user identification facilities to a Web application. Using session state without
    cookies, however, requires that the session identifier be placed in the query string, which is subject to the security issues
    stated in the query string section of this topic. For more information about using session state without cookies,
    see ASP.NET Web Site Administration.
   Extensibility You can customize and extend session state by writing your own session-state provider. Session state data
    can then be stored in a custom data format in a variety of data storage mechanisms, such as a database, an XML file, or
    even to a Web service. For more information, seeImplementing a Session-State Store Provider.
    Disadvantage of using session state are:
   Performance considerations Session-state variables stay in memory until they are either removed or replaced, and
    therefore can degrade server performance. Session-state variables that contain blocks of information, such as large
    datasets, can adversely affect Web-server performance as server load increases.
    Profile Properties
    ASP.NET provides a feature called profile properties, which allows you to store user-specific data. It is similar to session
    state, except that unlike session state, the profile data is not lost when a user‘s session expires. The profile properties
    feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user. The ASP.NET
    profile allows you to easily manage user information without requiring you to create and maintain your own database. In
    addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in
    your application. You can store objects of any type in the profile. The ASP.NET profile feature provides a generic storage
    system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe
    manner. For more information, see ASP.NET Profile Properties Overview.
    Advantages of using profile properties are:
   Data persistence Data placed in profile properties is preserved through IIS restarts and worker-process restarts without
    losing data because the data is stored in an external mechanism. Additionally, profile properties can be persisted across
    multiple processes, such as in a Web farm or a Web garden.
   Platform scalability Profile properties can be used in both multi-computer and multi-process configurations, therefore
    optimizing scalability scenarios.
   Extensibility In order to use profile properties, you must configure a profile provider. ASP.NET includes
    a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile
    provider class that stores profile data in a custom format and to a custom storage mechanism, such as an XML file, or even
    to a Web service. For more information, see ASP.NET Profile Providers and Implementing a Profile Provider.
    Disadvantages of using profile properties are:
   Performance considerations Profile properties are generally slower than using session state because instead of storing
    data in memory, the data is persisted to a data store.
   Additional configuration requirements Unlike session state, the profile properties feature requires a considerable
    amount of configuration to use. To use profile properties, you must not only configure a profile provider, but you must pre-
    configure all of the profile properties that you want to store. For more information, see ASP.NET Profile Properties
    Overview and Defining ASP.NET Profile Properties.
   Data maintenance Profile properties require a certain amount of maintenance. Because profile data is persisted to non-
    volatile storage, you must make sure that your application calls the appropriate cleanup mechanisms, which are provided
    by the profile provider, when data becomes stale.
    Database Support
    In some cases, you might want to use database support to maintain state on your Web site. Typically, database support is
    used in conjunction with cookies or session state. For example, it is common for an e-commerce Web site to maintain state
    information by using a relational database for the following reasons:
   Security
   Personalization
   Consistency
   Data mining
    The following are typical features of a cookie-supported database Web site:
   Security The visitor types an account name and password into a site logon page. The site infrastructure queries the
    database with the logon values to determine whether the user has rights to utilize your site. If the database validates the
    user information, the Web site will distribute a valid cookie containing a unique ID for that user on that client computer.
    The site grants access to the user.
   Personalization With security information in place, your site can distinguish each user by reading the cookie on the
    client computer. Typically, sites have information in the database that describes the preferences of a user (identified by a
    unique ID). This relationship is known as personalization. The site can research the user‟s preferences using the unique ID
    contained in the cookie, and then place content and information in front of the user that pertains to the user‟s specific
    wishes, reacting to the user‟s preferences over time.
   Consistency If you have created a commerce Web site, you might want to keep transactional records of purchases made
    for goods and services on your site. This information can be reliably saved in your database and referenced by the user‟s
    unique ID. It can be used to determine whether a purchase transaction has been completed, and to determine the course
    of action if a purchase transaction fails. The information can also be used to inform the user of the status of an order
    placed using your site.
   Data mining Information about your site usage, your visitors, or your product transactions can be reliably stored in a
    database. For example, your business development department might want to use the data collected from your site to
    determine next year‟s product line or distribution policy. Your marketing department might want to examine demographic
    information about users on your site. Your engineering and support departments might want to look at transactions and
    note areas where your purchasing process could be improved. Most enterprise-level relational databases, such as Microsoft
    SQL Server, contain an expansive toolset for most data mining projects.
    By designing the Web site to repeatedly query the database by using the unique ID during each general stage in the above
    scenario, the site maintains state. In this way, the user perceives that the site is remembering and reacting to him or her
    personally.
    Advantages of using a database to maintain state are:
   Security    Access to databases requires rigorous authentication and authorization.
   Storage capacity     You can store as much information as you like in a database.
   Data persistence     Database information can be stored as long as you like, and it is not subject to the availability of the
    Web server.
   Robustness and data integrity Databases include various facilities for maintaining good data, including triggers and
    referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in
    session state, for example), you can recover from errors more readily.
   Accessibility   The data stored in your database is accessible to a wide variety of information-processing tools.
   Widespread support There is a large range of database tools available, and many custom configurations are available.
    Disadvantages of using a database to maintain state are:
   Complexity Using a database to support state management requires that the hardware and software configurations be
    more complex.
   Performance considerations Poor construction of the relational data model can lead to scalability issues. Also,
    leveraging too many queries to the database can adversely affect server performance.
    Server-Side Method State Management Summary
    The following table lists the server-side state management options that are available with ASP.NET, and provides
    recommendations about when you should use each option.
    State               Recommended usage
    management
    option
    Application         Use when you are storing infrequently changed, global information that is used
    state               by many users, and security is not an issue. Do not store large quantities of
                        information in application state.
    Session state       Use when you are storing short-lived information that is specific to an individual
                        session and security is an issue. Do not store large quantities of information in
                        session state. Be aware that a session-state object will be created and maintained
                        for the lifetime of every session in your application. In applications hosting many
                        users, this can occupy significant server resources and affect scalability.
    Profile             Use when you are storing user-specific information that needs to be persisted
    properties          after the user session is expired and needs to be retrieved again on subsequent
                        visits to your application.
    Database            Use when you are storing large amounts of information, managing transactions,
    support             or the information must survive application and session restarts. Data mining is a
                        concern, and security is an issue.
    .NET Framework 4 – ASP.NET
    ASP.NET Cookies Overview
    A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The
    cookie contains information the Web application can read whenever the user visits the site.
    A Visual Studio project with source code is available to accompany this topic:Download.
    This topic contains the following:
   Scenarios
   Background
   Code Examples
   Class Reference
   Additional Resources
   What‟s New
    Scenarios
    Cookies provide a means in Web applications to store user-specific information. For example, when a user visits your site,
    you can use cookies to store user preferences or other information. When the user visits your Web site another time, the
    application can retrieve the information it stored earlier.Back to topBackground
    A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The
    cookie contains information the Web application can read whenever the user visits the site.For example, if a user requests
    a page from your site and your application sends not just a page, but also a cookie containing the date and time, when the
    user‟s browser gets the page, the browser also gets the cookie, which it stores in a folder on the user‟s hard disk.Later, if
    user requests a page from your site again, when the user enters the URL the browser looks on the local hard disk for a
    cookie associated with the URL. If the cookie exists, the browser sends the cookie to your site along with the page request.
    Your application can then determine the date and time that the user last visited the site. You might use the information to
    display a message to the user or check an expiration date.Cookies are associated with a Web site, not with a specific page,
    so the browser and server will exchange cookie information no matter what page the user requests from your site. As the
    user visits different sites, each site might send a cookie to the user‟s browser as well; the browser stores all the cookies
    separately.Cookies help Web sites store information about visitors. More generally, cookies are one way of maintaining
    continuity in a Web application—that is, of performing state management. Except for the brief time when they are actually
    exchanging information, the browser and Web server are disconnected. Each request a user makes to a Web server is
    treated independently of any other request. Many times, however, it‟s useful for the Web server to recognize users when
    they request a page. For example, the Web server on a shopping site keeps track of individual shoppers so the site can
    manage shopping carts and other user-specific information. A cookie therefore acts as a kind of calling card, presenting
    pertinent identification that helps an application know how to proceed.Cookies are used for many purposes, all relating to
    helping the Web site remember users. For example, a site conducting a poll might use a cookie simply as a Boolean value
    to indicate whether a user‟s browser has already participated in voting so that the user cannot vote twice. A site that asks
    a user to log on might use a cookie to record that the user already logged on so that the user does not have to keep
    entering credentials.
    Cookie Limitations
    Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small
    amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read
    user information from a database or other data store. (See the section ―Cookies and Security‖ below for information about
    security implications of storing user information.)
    Browsers also impose limitations on how many cookies your site can store on the user‘s computer. Most browsers allow
    only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute
    limit, usually 300, on the number of cookies they will accept from all sites combined.
    A cookie limitation that you might encounter is that users can set their browser to refuse cookies. If you define a P3P
    privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site. However, you
    might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common
    method for storing user information is session state, but session state depends on cookies, as explained later in the section
    ―Cookies and Session State.‖
     Note
    For more information on state management and options for saving information in a Web
    application, see ASP.NET State Management Overviewand ASP.NET State Management
    Recommendations.
    Although cookies can be very useful in your application, the application should not depend on being able to store cookies.
    Do not use cookies to support critical features. If your application must rely on cookies, you can test to see whether the
    browser will accept cookies. See the “Checking Whether a Browser Accepts Cookies” section later in this topic.




    Writing Cookies
    The browser is responsible for managing cookies on a user system. Cookies are sent to the browser via
    the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as
    theResponse property of your Page class. Any cookies that you want to send to the browser must be added to this
    collection. When creating a cookie, you specify a Name and Value. Each cookie must have a unique name so that it can be
    identified later when reading it from the browser. Because cookies are stored by name, naming two cookies the same will
    cause one to be overwritten.
You can also set a cookie‘s date and time expiration. Expired cookies are deleted by the browser when a user visits the site
that wrote the cookies. The expiration of a cookie should be set for as long as your application considers the cookie value
to be valid. For a cookie to effectively never expire, you can set the expiration date to be 50 years from now.
 Note
Users can clear the cookies on their computer at any time. Even if you store cookies with long
expiration times, a user might decide to delete all cookies, wiping out any settings you might
have stored in cookies.
If you do not set the cookie‟s expiration, the cookie is created but it is not stored on the user‟s hard disk. Instead, the
cookie is maintained as part of the user‟s session information. When the user closes the browser, the cookie is discarded. A
non-persistent cookie like this is useful for information that needs to be stored for only a short time or that for security
reasons should not be written to disk on the client computer. For example, non-persistent cookies are useful if the user is
working on a public computer, where you do not want to write the cookie to disk.
You can add cookies to the Cookies collection in a number of ways. The following example shows two methods to write
cookies:
VB
C#
C++
F#
JScript
Copy
Response.Cookies["userName"].Value = ―patrick‖;
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(1);
HttpCookie aCookie = new HttpCookie(―lastVisit‖);
aCookie.Value = DateTime.Now.ToString();
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);
The example adds two cookies to the Cookies collection, one named userName and the other named lastVisit. For the first
cookie, the values of the Cookies collection are set directly. You can add values to the collection this way
because Cookies derives from a specialized collection of typeNameObjectCollectionBase.
For the second cookie, the code creates an instance of an object of typeHttpCookie, sets its properties, and then adds it to
the Cookies collection via the Add method. When you instantiate an HttpCookie object, you must pass the cookie name as
part of the constructor.
Both examples accomplish the same task, writing a cookie to the browser. In both methods, the expiration value must be
of type DateTime. However, the lastVisited value is also a date-time value. Because all cookie values are stored as strings,
the date-time value has to be converted to a String .
Cookies with More Than One Value
You can store one value in a cookie, such as user name and last visit. You can also store multiple name-value pairs in a
single cookie. The name-value pairs are referred to as subkeys. (Subkeys are laid out much like a query string in a URL.)
For example, instead of creating two separate cookies named userName and lastVisit, you can create a single cookie
named userInfo that has the subkeys userName and lastVisit.
You might use subkeys for several reasons. First, it is convenient to put related or similar information into a single cookie.
In addition, because all the information is in a single cookie, cookie attributes such as expiration apply to all the
information. (Conversely, if you want to assign different expiration dates to different types of information, you should store
the information in separate cookies.)
A cookie with subkeys also helps you limit the size of cookie files. As noted earlier in the ―Cookie Limitations‖ section,
cookies are usually limited to 4096 bytes and you can‘t store more than 20 cookies per site. By using a single cookie with
subkeys, you use fewer of those 20 cookies that your site is allotted. In addition, a single cookie takes up about 50
characters for overhead (expiration information, and so on), plus the length of the value that you store in it, all of which
counts toward the 4096-byte limit. If you store five subkeys instead of five separate cookies, you save the overhead of the
separate cookies and can save around 200 bytes.
To create a cookie with subkeys, you can use a variation of the syntax for writing a single cookie. The following example
shows two ways to write the same cookie, each with two subkeys:
VB
C#
C++
F#
JScript
Copy
Response.Cookies["userInfo"]["userName"] = ―patrick‖;
Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();
Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);
HttpCookie aCookie = new HttpCookie(―userInfo‖);
    aCookie.Values["userName"] = ―patrick‖;
    aCookie.Values["lastVisit"] = DateTime.Now.ToString();
    aCookie.Expires = DateTime.Now.AddDays(1);
    Response.Cookies.Add(aCookie);
    Controlling Cookie Scope
    By default, all cookies for a site are stored together on the client, and all cookies are sent to the server with any request to
    that site. In other words, every page in a site gets all of the cookies for that site. However, you can set the scope of
    cookies in two ways:
   Limit the scope of cookies to a folder on the server, which allows you to limit cookies to an application on the site.
   Set scope to a domain, which allows you to specify which subdomains in a domain can access a cookie.
    Limiting Cookies to a Folder or Application
    To limit cookies to a folder on the server, set the cookie‘s Path property, as in the following example:
    VB
    C#
    C++
    F#
    JScript
    Copy
    HttpCookie appCookie = new HttpCookie(―AppCookie‖);
    appCookie.Value = ―written ‖ + DateTime.Now.ToString();
    appCookie.Expires = DateTime.Now.AddDays(1);
    appCookie.Path = ―/Application1″;
    Response.Cookies.Add(appCookie);
     Note
    You can also write cookies by adding them to the Cookies collection directly as shown in earlier
    examples.
    The path can either be a physical path under the site root or a virtual root. The effect will be that the cookie is available
    only to pages in the Application1 folder or virtual root. For example, if your site is called www.contoso.com, the cookie
    created in the previous example will be available to pages with the path http://www.contoso.com/Application1/ and to any
    pages beneath that folder. However, the cookie will not be available to pages in other applications such as
    http://www.contoso.com/Application2/ or just http://www.contoso.com/.




     Note
    In some browsers, the path is case sensitive. You cannot control how users type URLs into their
    browsers, but if your application depends on cookies tied to a specific path, be sure that the
    URLs in any hyperlinks you create match the case of the Path property value.




    Limiting Cookie Domain Scope
    By default, cookies are associated with a specific domain. For example, if your site is www.contoso.com, the cookies you
    write are sent to the server when users request any page from that site. (This might not include cookies with a specific
    path value.) If your site has subdomains—for example, contoso.com, sales.contoso.com, and support.contoso.com—then
    you can associate cookies with a specific subdomain. To do so, set the cookie‘sDomain property, as in this example:
    VB
    C#
    C++
    F#
    JScript
    Copy
    Response.Cookies["domain"].Value = DateTime.Now.ToString();
    Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);
    Response.Cookies["domain"].Domain = ―support.contoso.com‖;
When the domain is set in this way, the cookie will be available only to pages in the specified subdomain. You can also use
the Domain property to create a cookie that can be shared among multiple subdomains, as shown in the following
example:
Response.Cookies["domain"].Value = DateTime.Now.ToString();
Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);
Response.Cookies["domain"].Domain = ―contoso.com‖;
The cookie will then be available to the primary domain as well as to sales.contoso.com and support.contoso.com domains.
Reading Cookies
When a browser makes a request to the server, it sends the cookies for that server along with the request. In your
ASP.NET applications, you can read the cookies using the HttpRequest object, which is available as theRequest property of
your Page class. The structure of the HttpRequestobject is essentially the same as that of the HttpResponse object, so you
can read cookies out of the HttpRequest object much the same way you wrote cookies into the HttpResponse object. The
following code example shows two ways to get the value of a cookie named username and display its value in
a Label control:
if(Request.Cookies["userName"] != null)
    Label1.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);
if(Request.Cookies["userName"] != null)
{
    HttpCookie aCookie = Request.Cookies["userName"];
    Label1.Text = Server.HtmlEncode(aCookie.Value);
}
Before trying to get the value of a cookie, you should make sure that the cookie exists; if the cookie does not exist, you
will get aNullReferenceException exception. Notice also that the HtmlEncode method was called to encode the contents of a
cookie before displaying it in the page. This makes certain that a malicious user has not added executable script into the
cookie. For more about cookie security, see the ―Cookies and Security‖ section.
 Note
Because different browsers store cookies differently, different browsers on the same computer
won’t necessarily be able to read each other’s cookies. For example, if you use Internet Explorer
to test a page one time, but then later use a different browser to test again, the second browser
won’t find the cookies saved by Internet Explorer.
Reading the value of a subkey in a cookie is likewise similar to setting it. The following code example shows one way to get
the value of a subkey:
VB
C#
C++
F#
JScript
Copy
if(Request.Cookies["userInfo"] != null)
{
   Label1.Text =
      Server.HtmlEncode(Request.Cookies["userInfo"]["userName"]);
   Label2.Text =
      Server.HtmlEncode(Request.Cookies["userInfo"]["lastVisit"]);
}
In the preceding example, the code reads the value of the subkey lastVisit, which was set earlier to the string
representation of a DateTime value. Cookies store values as strings, so if you want to use the lastVisit
DateTime dt;
dt = DateTime.Parse(Request.Cookies["userInfo"]["lastVisit"]);
The subkeys in a cookie are typed as a collection of typeNameValueCollection. Therefore, another way to get an individual
subkey is to get the subkeys collection and then extract the subkey value by name, as
if(Request.Cookies["userInfo"] != null)
{
   System.Collections.Specialized.NameValueCollection
      UserInfoCookieCollection;
   UserInfoCookieCollection = Request.Cookies["userInfo"].Values;
   Label1.Text =
      Server.HtmlEncode(UserInfoCookieCollection["userName"]);
   Label2.Text =
      Server.HtmlEncode(UserInfoCookieCollection["lastVisit"]);
}
Changing a Cookie’s Expiration Date
The browser is responsible for managing cookies, and the cookie‘s expiration time and date help the browser manage its
store of cookies. Therefore, although you can read the name and value of a cookie, you cannot read the cookie‘s expiration
date and time. When the browser sends cookie information to the server, the browser does not include the expiration
information. (The cookie‘s Expires property always returns a date-time value of zero.) If you are concerned about the
expiration date of a cookie, you must reset it, which is covered in the ―Modifying and Deleting Cookies‖ section.
 Note
You can read the Expires property of a cookie that you have set in theHttpResponse object,
before the cookie has been sent to the browser. However, you cannot get the expiration back in
the HttpRequest object.




Reading Cookie Collections
You might occasionally need to read through all the cookies available to the page. To read the names and values of all the
cookies available to the page, you can loop through the Cookies collection using code such as the following.
System.Text.StringBuilder output = new System.Text.StringBuilder();
HttpCookie aCookie;
for(int i=0; i<Request.Cookies.Count; i++)
{
   aCookie = Request.Cookies[i];
   output.Append(―Cookie name = ‖ + Server.HtmlEncode(aCookie.Name)
      + ―<br />‖);
   output.Append(―Cookie value = ‖ + Server.HtmlEncode(aCookie.Value)
      + ―<br /><br />‖);
}
Label1.Text = output.ToString();
 Note
When you run this code, you might see a cookie named ASP.NET_SessionId. That is a cookie
that ASP.NET uses to store a unique identifier for your session. The session cookie is not
persisted on your hard disk. For more about session cookies, see the “Cookies and Session State”
later in this topic.
A limitation of the preceding example is that if the cookie has subkeys, the display shows the subkeys as a single
name/value string. You can read a cookie‟s HasKeys property to determine whether the cookie has subkeys. If so, you can
read the subkey collection to get individual subkey names and values. You can read subkey values from the Values
collection directly by index value. The corresponding subkey names are available in the AllKeys member of
theValues collection, which returns an array of strings. You can also use the Keysmember of the Values collection.
However, the AllKeys property is cached the first time it is accessed. In contrast, the Keys property builds an array each
time it is accessed. For this reason, the AllKeys property is much faster on subsequent accesses within the context of the
same page request.
The following example shows a modification of the preceding example. It uses the HasKeys property to test for subkeys,
and if subkeys are detected, the example gets subkeys from the Values collection:
for(int i=0; i<Request.Cookies.Count; i++)
{
   aCookie = Request.Cookies[i];
   output.Append(“Name = ” + aCookie.Name + “<br />”);
   if(aCookie.HasKeys)
   {
       for(int j=0; j<aCookie.Values.Count; j++)
       {
          subkeyName = Server.HtmlEncode(aCookie.Values.AllKeys[j]);
          subkeyValue = Server.HtmlEncode(aCookie.Values[j]);
          output.Append(―Subkey name = ‖ + subkeyName + ―<br />‖);
          output.Append(―Subkey value = ‖ + subkeyValue +
             ―<br /><br />‖);
       }
   }
   else
  {
      output.Append(―Value = ‖ + Server.HtmlEncode(aCookie.Value) +
        ―<br /><br />‖);
   }
}
Label1.Text = output.ToString();
Alternatively, you can extract the subkeys as a NameValueCollection object as shown in the following example:
System.Text.StringBuilder output = new System.Text.StringBuilder();
HttpCookie aCookie;
string subkeyName;
string subkeyValue;
for (int i = 0; i < Request.Cookies.Count; i++)
{
   aCookie = Request.Cookies[i];
   output.Append(―Name = ‖ + aCookie.Name + ―<br />‖);
   if (aCookie.HasKeys)
   {
       System.Collections.Specialized.NameValueCollection CookieValues =
          aCookie.Values;
       string[] CookieValueNames = CookieValues.AllKeys;
       for (int j = 0; j < CookieValues.Count; j++)
       {
          subkeyName = Server.HtmlEncode(CookieValueNames[j]);
          subkeyValue = Server.HtmlEncode(CookieValues[j]);
          output.Append(―Subkey name = ‖ + subkeyName + ―<br />‖);
          output.Append(―Subkey value = ‖ + subkeyValue +
              ―<br /><br />‖);
       }
   }
   else
   {
       output.Append(―Value = ‖ + Server.HtmlEncode(aCookie.Value) +
          ―<br /><br />‖);
   }
}
Label1.Text = output.ToString();
Modifying and Deleting Cookies
You cannot directly modify a cookie. Instead, changing a cookie consists of creating a new cookie with new values and
then sending the cookie to the browser to overwrite the old version on the client. The following code example shows how
you can change the value of a cookie that stores a count of the user‘s visits to the site:
int counter;
if (Request.Cookies["counter"] == null)
    counter = 0;
else
{
    counter = int.Parse(Request.Cookies["counter"].Value);
}
counter++;
Response.Cookies["counter"].Value = counter.ToString();
Response.Cookies["counter"].Expires = DateTime.Now.AddDays(1);
Deleting Cookies
Deleting a cookie—physically removing it from the user‘s hard disk—is a variation on modifying it. You cannot directly
remove a cookie because the cookie is on the user‘s computer. However, you can have the browser delete the cookie for
you. The technique is to create a new cookie with the same name as the cookie to be deleted, but to set the cookie‘s
expiration to a date earlier than today. When the browser checks the cookie‘s expiration, the browser will discard the now-
outdated cookie. The following code example shows one way to delete all the cookies available to the application:
HttpCookie aCookie;
string cookieName;
int limit = Request.Cookies.Count;
for (int i=0; i<limit; i++)
{
   cookieName = Request.Cookies[i].Name;
    aCookie = new HttpCookie(cookieName);
    aCookie.Expires = DateTime.Now.AddDays(-1);
    Response.Cookies.Add(aCookie);
}
Modifying or Deleting Subkeys
Modifying an individual subkey is the same as creating it, as shown in the following example:
Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();
Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);
To delete an individual subkey, you manipulate the cookie‘s Valuescollection, which holds the subkeys. You first recreate
the cookie by getting it from the Cookies object. You can then call the Remove method of theValues collection, passing to
the Remove method the name of the subkey to delete. You then add the cookie to the Cookies collection so it will be sent
in its modified form back to the browser. The following code example shows how to delete a subkey. In the sample, the
name of the subkey to remove is specified in a variable.
string subkeyName;
subkeyName = ―userName‖;
HttpCookie aCookie = Request.Cookies["userInfo"];
aCookie.Values.Remove(subkeyName);
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);
Cookies and Security
The security issues with cookies are similar to those of getting data from the client. In your application, cookies are
another form of user input and are therefore subject to examining and spoofing. A user can as a minimum see the data
that you store in a cookie, since the cookie is available on the user‘s own computer. The user can also change the cookie
before the browser sends it to you.
You should never store sensitive data in a cookie, such as user names, passwords, credit card numbers, and so on. Do not
put anything in a cookie that should not be in the hands of a user or of someone who might somehow steal the cookie.
Similarly, be suspicious of information you get out of a cookie. Do not assume that the data is the same as when you wrote
it out; use the same safeguards in working with cookie values that you would with data that a user has typed into a Web
page. The examples earlier in this topic showed HTML-encoding the contents of a cookie before displaying the value in a
page, as you would before displaying any information you get from users.
Cookies are sent between browser and server as plain text, and anyone who can intercept your Web traffic can read the
cookie. You can set a cookie property that causes the cookie to be transmitted only if the connection uses the Secure
Sockets Layer (SSL). SSL does not protect the cookie from being read or manipulated while it is on the user‘s computer,
but it does prevent the cookie from being read while in transit because the cookie is encrypted. For more information,
see Basic Security Practices for Web Applications.
Determining Whether a Browser Accepts Cookies
Users can set their browser to refuse cookies. No error is raised if a cookie cannot be written. The browser likewise does
not send any information to the server about its current cookie settings.
 Note
The Cookies property does not indicate whether cookies are enabled. It indicates only whether
the current browser inherently supports cookies.
One way to determine whether cookies are accepted is by trying to write a cookie and then trying to read it back again. If
you cannot read the cookie you wrote, you assume that cookies are turned off in the browser.
The following code example shows how you might test whether cookies are accepted. The sample consists of two pages.
The first page writes out a cookie, and then redirects the browser to the second page. The second page tries to read the
cookie. It in turn redirects the browser back to the first page, adding to the URL a query string variable with the results of
the test.
The code for the first page (AcceptsCookies.aspx) looks like the following example:
protected void Page_Load(object sender, EventArgs e)
{
   if (!Page.IsPostBack)
   {
       if (Request.QueryString["AcceptsCookies"] == null)
       {
           Response.Cookies["TestCookie"].Value = ―ok‖;
           Response.Cookies["TestCookie"].Expires =
             DateTime.Now.AddMinutes(1);
           Response.Redirect(―TestForCookies.aspx?redirect=‖ +
             Server.UrlEncode(Request.Url.ToString()));
       }
       else
          {
              Label1.Text = ―Accept cookies = ‖ +
                Server.UrlEncode(
                Request.QueryString["AcceptsCookies"]);
          }
      }
    }
    The page first tests to see if this is a postback, and if not, the page looks for the query string variable name
    AcceptsCookies that contains the test results. If there is no query string variable, the test has not been completed, so the
    code writes out a cookie named TestCookie. After writing out the cookie, the sample calls Redirect to transfer to the test
    page TestForCookies.aspx. Appended to the URL of the test page is a query string variable named redirect containing the
    URL of the current page; this will allow you to redirect back to this page after performing the test.
    The test page can consist entirely of code; it does not need to contain controls. The following example illustrates the test
    page (TestForCookies.aspx).
    protected void Page_Load(object sender, EventArgs e)
    {
       string redirect = Request.QueryString["redirect"];
       string acceptsCookies;
       if(Request.Cookies["TestCookie"] ==null)
          acceptsCookies = ―no‖;
       else
       {
          acceptsCookies = ―yes‖;
          // Delete test cookie.
          Response.Cookies["TestCookie"].Expires =
              DateTime.Now.AddDays(-1);
       }
       Response.Redirect(redirect + ―?AcceptsCookies=‖ + acceptsCookies,
       true);
    }
    After reading the redirect query string variable, the code tries to read the cookie. For housekeeping purposes, if the cookie
    exists, it is immediately deleted. When the test is finished, the code constructs a new URL from the URL passed to it in the
    redirect query string variable. The new URL also includes a query string variable containing test results. The final step is to
    use the new URL to redirect the browser to the original page.
    An improvement in the example would be to keep the cookie test results in a persistent store such as a database so that
    the test does not have to be repeated each time the user views the original page. (Storing the test results in session state
    by default requires cookies.)
    Cookies and Session State
    When a user navigates to your site, the server establishes a unique session for that user that lasts for the duration of the
    user‘s visit. For each session, ASP.NET maintains session state information where applications can store user-specific
    information. For more information, see ASP.NET Session State Overview topic.
    ASP.NET must track a session ID for each user so that it can map the user to session state information on the server. By
    default, ASP.NET uses a non-persistent cookie to store the session state. However, if a user has disabled cookies on the
    browser, session state information cannot be stored in a cookie.
    ASP.NET offers an alternative in the form of cookieless sessions. You can configure your application to store session IDs
    not in a cookie, but in the URLs of pages in your site. If your application relies on session state, you might consider
    configuring it to use cookieless sessions. However, under some limited circumstances, if the user shares the URL with
    someone else—perhaps to send the URL to a colleague while the user‘s session is still active—then both users can end up
    sharing the same session, with unpredictable results. For more information on configuring your application to use
    cookieless sessions, see the ASP.NET State Management Overviewtopic.
    ASP.NET View State Overview
    View state is the method that the ASP.NET page framework uses to preserve page and control values between round trips.
    When the HTML markup for the page is rendered, the current state of the page and values that must be retained during
    postback are serialized into base64-encoded strings. This information is then put into the view state hidden field or fields.
    This topic contains the following sections:
   Scenarios
   Features
   Background
   Class Reference
    Scenarios
    View state is used automatically by the ASP.NET page framework to persist information that must be preserved between
    postbacks. This information includes any non-default values of controls.You can also use view state to store application
    data that is specific to a page.Back to topFeatures
    View state is a repository in an ASP.NET page that can store values that have to be retained during postback. The page
    framework uses view state to persist control settings between postbacks.You can use view state in your own applications
    to do the following:
   Keep values between postbacks without storing them in session state or in a user profile.
   Store the values of page or control properties that you define.
   Create a custom view state provider that lets you store view state information in a SQL Server database or in another data
    store.
    For example, you can store information in view state that your code can access during the page load event the next time
    that the page is sent to the server. For usage recommendations, see ASP.NET State Management Recommendations.
    Back to top
    Background
    A Web application is stateless. A new instance of the Web page class is created every time that the page is requested from
    the server. This would ordinarily mean that all information in the page and in its controls would be lost with each round
    trip. For example, by default if a user enters information into a text box on an HTML Web page, that information is sent to
    the server. However, it is not returned to the browser in the response.To overcome this intrinsic limitation of Web
    programming, the ASP.NET page framework includes several state-management features to preserve page and control
    values between round trips to the Web server. One of these features is view state. For information about other state
    management features, see ASP.NET State Management Overview.By default, the ASP.NET page framework uses view state
    to preserve page and control values between round trips. When the HTML for the page is rendered, the current state of the
    page and values that must be retained during postback are serialized into base64-encoded strings. They are then put into
    a hidden field or fields in the page.You can access view state in your code by using the page‟s ViewState property.
    The ViewState property is a dictionary that contains key/value pairs that contain the view state data.
     Security Note
    It is easy for a malicious user to see and modify the contents of a hidden field. For more
    information about how to secure view state data, seeSecuring View State later in this topic.
    For recommendations about when you should store information in view state, see ASP.NET State Management
    Recommendations.
    You can change the default behavior and store view state in another location such as a SQL Server database by
    implementing a custom PageStatePersisterclass to store page data. For an example of how to store page state in a stream
    instead of in a hidden field, see the example for the PageStatePersister class.




    Considerations for Using View State
    View state provides state information for a specific ASP.NET page. If you need to use information on more than one page,
    or if you need the information to persist across visits to the Web site, you must use another method for maintaining state.
    You can use application state, session state, or profile properties. For more information, see How to: Pass Values Between
    ASP.NET Web Pages.
    View state information is serialized into XML and then encoded by using base-64 encoding, which can generate large
    amounts of data. When the page is posted to the server, the contents of view state are sent as part of the page postback
    information. If view state contains a large amount of information, it can affect performance of the page. Test the
    performance of your pages by using typical data for your application to determine whether the size of view state is causing
    performance problems.
    Another consideration is that if the amount of data in a hidden field becomes large, some proxies and firewalls will prevent
    access to the page that contains them. Because the maximum allowed amount can vary with different firewall and proxy
    implementations, large hidden fields can cause intermittent problems. If the amount of data that is stored in
    the ViewStateproperty exceeds the value specified in the page‘sMaxPageStateFieldLength property, the page splits view
    state into multiple hidden fields. This reduces the size of individual hidden fields below the size that firewalls reject.
    View state is enabled by default, but some controls on a page might not need view state. For example, if a control is
    refreshed from the data store on each postback, you can turn view state off for that control in order to reduce the size of
    view state.
    You can configure controls so that view state is disabled by default for all controls within a page or a container control, and
    you can then enable view state for specific controls. You can also configure controls so that view state is disabled and
    cannot be enabled for child controls.
    To disable view state for a control by default so that it can be enabled for child controls, set the ViewStateMode property of
    the control to Disabled. To disable view state by default for an entire page, set the ViewStateMode attribute of
    the @ Page directive to Disabled.
    To disable view state for a control and its children so that it cannot be enabled for child controls, set
    the EnableViewState property of the control to false. To disable view state for an entire page and all of its child controls,
    set the EnableViewState attribute of the @ Page directive to false.
 Note
Even when you explicitly turn view state off, a hidden field is still sent to the browser to indicate
that postback is occurring for the page.
For alternatives to using view state, see ASP.NET State Management Recommendations.
Some mobile devices do not allow hidden fields at all. Therefore, view state will not work for those devices. For more
information and alternatives, see ASP.NET Web Sites for Mobile Devices.




Control State
In addition to view state, ASP.NET supports control state. The page uses control state to persist control information that
must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control
state is stored in one or more hidden fields.
Saving Values in View State
You can access view state information by using the page‘s ViewStateproperty, which exposes a dictionary object. You can
use this dictionary to store custom values. A typical use is to store the value of custom properties that you define in the
page.
Because view state is sent as a hidden field, you can make changes to view state until the
page‘s PreRenderComplete event. After the page is rendered to the browser, changes to view state will not be saved.
The information in the hidden view state field can be seen by users if they view the source of the Web page and can
decode base-64 encoded strings. This creates a potential security issue. For more information about security issues with
view state, see Securing View State later in this topic.
 Note
To use the ViewState property, the ASP.NET Web page must have a form element that has the
attribute runat=”server”.
To save a value to view state, create a new item that contains the value to save and add the item to the view state
dictionary. The following example shows an ASP.NET Web page with code that saves a string and an integer value in view
state.
<%@ Page Language=”C#” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd”>
<script runat=”server”>
  // Sample ArrayList for the page.
  ArrayList PageArrayList;
  ArrayList CreateArray()
  {
    // Create a sample ArrayList.
    ArrayList result = new ArrayList(4);
    result.Add(―item 1″);
    result.Add(―item 2″);
    result.Add(―item 3″);
    result.Add(―item 4″);
    return result;
  }
  void Page_Load(object sender, EventArgs e)
  {
    if (ViewState["arrayListInViewState"] != null)
    {
      PageArrayList = (ArrayList)ViewState["arrayListInViewState"];
    }
    else
    {
      // ArrayList isn‘t in view state, so it must be created and populated.
      PageArrayList = CreateArray();
    }
    // Code that uses PageArrayList.
  }
  void Page_PreRender(object sender, EventArgs e)
  {
    // Save PageArrayList before the page is rendered.
    ViewState.Add(―arrayListInViewState‖, PageArrayList);
     }
    </script>
    <html xmlns=‖http://www.w3.org/1999/xhtml‖ >
    <head runat=‖server‖>
       <title>View state sample</title>
    </head>
    <body>
       <form id=‖form1″ runat=‖server‖>
       <div>
       </div>
       </form>
    </body>
    </html>
    Data Types You Can Store in View State
    You can store objects of the following types in view state:
   Strings
   Integers
   Boolean values
   Array objects
   ArrayList objects
   Hash tables
   Custom type converters (see the TypeConverter class for more information)
    You can store other types of data also, but the class must be compiled with the Serializable attribute so that its values can
    be serialized for view state.
    Reading Values from View State
    To read a value from view state, you get the ViewState property of page and then read the value from the view state
    dictionary.
    The following example shows how you can get an ArrayList object named arrayListInViewState from view state and then
    bind a GridView control to the object as a data source.
    arrayList = new ArrayList();
    arrayList = (ArrayList)ViewState["arrayListInViewState"];
    this.GridView1.DataSource = arrayList;
    this.GridView1.DataBind();
    Values in view state are typed as String. In Visual Basic, if you set Option Strict On, you must cast view state values to the
    appropriate type before you use them, as shown in the previous example. In C#, you must always cast to the appropriate
    type when you read view state values.
    If you try to get a value out of view state that does not exist, no exception is thrown. To make sure that a value is in view
    state, check first whether the object exists. The following example shows how to check for a view state entry.
    if (ViewState["color"] == null)
        // No such value in view state, take appropriate action.
    If you try to use a nonexistent view state entry in some other way (for example, to examine its type),
    a NullReferenceException exception is thrown.
    Back to top
    Securing View State
    By default, view state data is stored in the page in a hidden field and is encoded using base64 encoding. In addition, a
    hash of the view state data is created from the data by using a machine authentication code (MAC) key. The hash value is
    added to the encoded view state data and the resulting string is stored in the page. When the page is posted back to the
    server, the ASP.NET page framework re-computes the hash value and compares it with the value stored in view state. If
    the hash values do not match, an exception is raised that indicates that view state data might be invalid.
    By creating a hash value, the ASP.NET page framework can test whether the view state data has been corrupted or
    tampered with. However, even if it is not tampered with, view state data can still be intercepted and read by malicious
    users.
    Usign the MAC for Computing the View State Hash Value
    The MAC key that is used to compute the view state hash value is either auto-generated or specified in the Machine.config
    file. If the key is auto-generated, it is created based on the MAC address of the computer, which is the unique GUID value
    of the network adapter in that computer.
    It can be difficult for malicious users to reverse-engineer the MAC key based on the hash value in view state. Thus, MAC
    encoding is a reasonably reliable way to determine whether view state data has been changed.
    In general, the larger the MAC key that is used to generate the hash, the less likely it is that the hash value for different
    strings will be the same. When the key is auto-generated, ASP.NET uses SHA-1 encoding to create a large key. However,
    in a Web-farm environment, the key must be the same across all the servers. If the key is not the same, and the page is
    posted back to a different server than the one that created the page, the ASP.NET page framework will raise an exception.
    Therefore, in a Web farm environment, you should specify a key in the Machine.config file instead of letting ASP.NET auto-
    generate one. In that case, make sure that you create a key that is long enough to offer sufficient security for the hashed
    value. However, the longer the key is, the more time it takes to create a hash. Therefore, you must weigh security needs
    versus performance needs.
    Encrypting View State
    Although MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data.
    You can prevent people from viewing this data in two ways: by transmitting the page over SSL, and by encrypting the view
    state data. Requiring the page to be sent over SSL can help prevent data-packet sniffing and unauthorized data access by
    people who are not the intended recipients of the page.
    However, the user who requested the page can still view the view state data because SSL decrypts the page to display it in
    the browser. This is fine if you are not concerned about authorized users having access to view state data. However, in
    some cases, controls might use view state to store information that no users should have access to. For example, the page
    might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain
    sensitive data, such as customer IDs, you should encrypt the view state data in addition to or instead of sending the page
    over SSL.
    To encrypt the data, set the page‘s ViewStateEncryptionMode property to true. If you store information in view state, you
    can use regular read and write techniques; the page handles all encryption and decryption for you. Encrypting view state
    data can affect the performance of your application. Therefore, do not use encryption unless you need it.
    Control State Encryption
    Controls that use control state can require that view state be encrypted by calling
    the RegisterRequiresViewStateEncryption method. If any control in the page requires that view state be encrypted, all view
    state in the page will be encrypted.
    Per-user View State Encoding
    If a Web site authenticates users, you can set the ViewStateUserKeyproperty in the Page_Init event handler to associate
    the page‘s view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid,
    pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link
    that sends the page to the server by using the victim‘s identity.
    When the ViewStateUserKey property is set, the attacker‘s identity is used to create the hash of the view state of the
    original page. When the victim is lured into resending the page, the hash values will be different because the user keys are
    different. The page will fail verification and an exception will be thrown.
    You must associate the ViewStateUserKey property with a unique value for each user, such as the user name or identifier.
    Securing Configuration in Shared Hosting Environment
    In a shared hosting environment, malicious users can potentially modify state-management properties that might affect
    other applications on the computer. This can be done through direct modification of the Machine.config file, modification by
    way of the configuration classes, and other administration and configuration tools. You can help prevent modification to
    your application configuration by encrypting sections of configuration files. For more information, see Encrypting
    Configuration Information Using Protected Configuration
    Class Reference
    ViewState          Provides a dictionary object for retaining values between requests for the same
                       page.
    PageStatePersister Provides a means to define a custom mechanism for storing view state
                       information, such as in a SQL Server database.
    ASP.NET Session State Overview
    Use ASP.NET session state to store and retrieve values for a user.
    This topic contains:

   Background
   Code Examples
   Class Reference
    A Visual Studio project with source code is available to accompany this topic: Download.
    Background
    ASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web
    application. HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an
    independent request. The server retains no knowledge of variable values that were used during previous requests.
    ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides
    a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all
    ASP.NET applications.Alternatives to session state include the following:
   Application state, which stores variables that can be accessed by all users of an ASP.NET application.
   Profile properties, which persists user values in a data store without expiring them.
   ASP.NET caching, which stores values in memory that is available to all ASP.NET applications.
   View state, which persists values in a page.
   Cookies.
   The query string and fields on an HTML form that are available from an HTTP request.
    For a comparison of different state-management options, see ASP.NET State Management Recommendations.
    Session Variables
    Session variables are stored in a SessionStateItemCollection object that is exposed through
    the HttpContext.Session property. In an ASP.NET page, the current session variables are exposed through the Session
    property of the Page object.
    The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are
    created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to
    the collection. The following example shows how to create session variables in an ASP.NET page for the first and last name
    of a user, and set them to values retrieved from TextBox controls.
    Session["FirstName"] = FirstNameTextBox.Text;
    Session["LastName"] = LastNameTextBox.Text;
    Session variables can be any valid .NET Framework type. The following example stores an ArrayList object in a session
    variable named StockPicks. The value returned by the StockPicks session variable must be cast to the appropriate type
    when you retrieve it from the SessionStateItemCollection.
    // When retrieving an object from session state, cast it to
    // the appropriate type.
    ArrayList stockPicks = (ArrayList)Session["StockPicks"];
    // Write the modified stock picks list back to session state.
    Session["StockPicks"] = stockPicks;
     Note
    When you use a session-state mode other than InProc, the session-variable type must be either a
    primitive .NET type or serializable. This is because the session-variable value is stored in an
    external data store. For more information, see Session-State Modes.




    Session Identifiers
    Sessions are identified by a unique identifier that can be read by using theSessionID property. When session state is
    enabled for an ASP.NET application, each request for a page in the application is examined for aSessionID value sent from
    the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is
    sent to the browser with the response.
    By default, SessionID values are stored in a cookie. However, you can also configure the application to
    store SessionID values in the URL for a ―cookieless‖ session.
    A session is considered active as long as requests continue to be made with the same SessionID value. If the time between
    requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired.
    Requests made with an expired SessionIDvalue result in a new session.
     Security Note
    SessionID values are sent in clear text, whether as a cookie or as part of the URL. A malicious
    user could get access to the session of another user by obtaining the SessionID value and
    including it in requests to the server. If you are storing sensitive information in session state, it is
    recommended that you use SSL to encrypt any communication between the browser and server
    that includes the SessionID value.



    Cookieless SessionIDs
By default, the SessionID value is stored in a non-expiring session cookie in the browser. However, you can specify that
session identifiers should not be stored in a cookie by setting the cookieless attribute to true in thesessionState section of
the Web.config file.
The following example shows a Web.config file that configures an ASP.NET application to use cookieless session identifiers.
Copy
<configuration>
  <system.web>
   <sessionState cookieless=‖true‖
     regenerateExpiredSessionId=‖true‖ />
  </system.web>
</configuration>
ASP.NET maintains cookieless session state by automatically inserting a unique session ID into the page‘s URL. For
example, the following URL has been modified by ASP.NET to include the unique session ID lit3py55t21z5v55vlm25s55:
Copy
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
When ASP.NET sends a page to the browser, it modifies any links in the page that use an application-relative path by
embedding a session ID value in the links. (Links with absolute paths are not modified.) Session state is maintained as
long as the user clicks links that have been modified in this manner. However, if the client rewrites a URL that is supplied
by the application, ASP.NET may not be able to resolve the session ID and associate the request with an existing session.
In that case, a new session is started for the request.
The session ID is embedded in the URL after the slash that follows the application name and before any remaining file or
virtual directory identifier. This enables ASP.NET to resolve the application name before involving theSessionStateModule in
the request.
 Note
To improve the security of your application, you should allow users to log out of your
application, at which point the application should call theAbandon method. This reduces the
potential for a malicious user to get the unique identifier in the URL and use it to retrieve private
user data stored in the session.




Regenerating Expired Session Identifiers
By default, the session ID values that are used in cookieless sessions are recycled. That is, if a request is made with a
session ID that has expired, a new session is started by using the SessionID value that is supplied with the request. This
can result in a session unintentionally being shared when a link that contains a cookieless SessionID value is used by
multiple browsers. (This can occur if the link is passed through a search engine, through an e-mail message, or through
another program.) You can reduce the chance of session data being shared by configuring the application not to recycle
session identifiers. To do this, set the regenerateExpiredSessionId attribute of the sessionState configuration element to
true. This generates a new session ID when a cookieless session request is made with an expired session ID.
 Note
If the request that is made with the expired session ID is made by using the HTTP POST method,
any posted data will be lost when regenerateExpiredSessionId is true. This is because ASP.NET
performs a redirect to make sure that the browser has the new session identifier in the URL.




Custom Session Identifiers
You can implement a custom class to supply and validate SessionID values. To do so, create a class that inherits
the SessionIDManager class and override the CreateSessionID and Validate methods with your own implementations. For
an example, see the example provided for theCreateSessionID method.
You can replace the SessionIDManager class by creating a class that implements the ISessionIDManager interface. For
example, you might have a Web application that associates a unique identifier with non-ASP.NET pages (such as HTML
pages or images) by using an ISAPI filter. You can implement a custom SessionIDManager class to use this unique
identifier with ASP.NET session state. If your custom class supports cookieless session identifiers, you must implement a
solution for sending and retrieving session identifiers in the URL.
    Session Modes
    ASP.NET session state supports several storage options for session variables. Each option is identified as a session-
    state Mode type. The default behavior is to store session variables in the memory space of the ASP.NET worker process.
    However, you can also specify that session state should be stored in a separate process, in a SQL Server database, or in a
    custom data source. If you do not want session state enabled for your application, you can set the session mode to Off.
    For more information, see Session-State Modes.
    Session Events
    ASP.NET provides two events that help you manage user sessions. TheSession_OnStart event is raised when a new
    session starts, and theSession_OnEnd event is raised when a session is abandoned or expires. Session events are
    specified in the Global.asax file for an ASP.NET application.
    The Session_OnEnd event is not supported if the session Mode property is set to a value other than InProc, which is the
    default mode.
     Note
    If the Global.asax file or Web.config file for an ASP.NET application is modified, the
    application will be restarted and any values stored in application state or session state will be
    lost. Be aware that some anti-virus software can update the last-modified date and time of the
    Global.asax or Web.config file for an application.
    For more information, see Session-State Events.




    Configuring Session State
    Session state is configured by using the sessionState element of the system.web configuration section. You can also
    configure session state by using the EnableSessionState value in the @ Page directive.
    The sessionState element enables you to specify the following options:
   The mode in which the session will store data.
   The way in which session identifier values are sent between the client and the server.
   The session Timeout value.
   Supporting values that are based on the session Mode setting.
    The following example shows a sessionState element that configures an application for SQLServer session mode. It sets
    the Timeout value to 30 minutes, and specifies that session identifiers are stored in the URL.
    <sessionState mode=‖SQLServer‖
      cookieless=‖true ―
      regenerateExpiredSessionId=‖true ―
      timeout=‖30″
      sqlConnectionString=‖Data Source=MySqlServer;Integrated Security=SSPI;‖
      stateNetworkTimeout=‖30″/>
    You can disable session state for an application by setting the session-state mode to Off. If you want to disable session
    state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to
    false. The EnableSessionState value can also be set to ReadOnly to provide read-only access to session variables.
    Concurrent Requests and Session State
    Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent
    requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the
    same session (by using the same SessionID value), the first request gets exclusive access to the session information. The
    second request executes only after the first request is finished. (The second session can also get access if the exclusive
    lock on the information is freed because the first request exceeds the lock time-out.) If theEnableSessionState value in the
    @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on
    the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write
    request for session data to clear.
    Back to top
    Code Examples
    How to: Save Values in Session StateHow to: Read Values from Session StateImplementing a Session-State Store
    ProviderBack to topClass Reference
    The following table lists key classes that relate to session state are in theSystem.Web.SessionState namespace.
    Member                                   Description
    SessionIDManager                         Manages unique identifiers for ASP.NET session state.
    SessionStateItemCollection               Used to store session state variables.
    ASP.NET Application State Overview
    Application state is a data repository available to all classes in an ASP.NET application. Application state is stored in
    memory on the server and is faster than storing and retrieving information in a database. Unlike session state, which is
    specific to a single user session, application state applies to all users and sessions. Therefore, application state is a useful
    place to store small amounts of often-used data that does not change from one user to another. For information on saving
    data on a per-user basis see ASP.NET Session State Overview and ASP.NET Profile Properties Overview.
    Using Application State
    You can access members of objects stored in application state without having to reference the Application collection. The
    following code example shows how to reference a member of an object defined in the StaticObjects collection of application
    state. Notice that the label identifier defined in Global.asax is used as the variable name.
    protected void Page_Load(Object sender, EventArgs e)
    {
        Label1.Text = MyInfo.Title;
    }
    Application State Considerations
    When using application state, you must be aware of the following important considerations:
   Resources Because it is stored in memory, application state is very fast compared to saving data to disk or a database.
    However, storing large blocks of data in application state can fill up server memory, causing the server to page memory to
    disk. As an alternative to using application state, you can use the ASP.NET cache mechanism for storing large amounts of
    application data. The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively
    manages the cache and will remove items when memory becomes scarce. For more information see ASP.NET Caching
    Overview.
   Volatility Because application state is stored in server memory, it is lost whenever the application is stopped or
    restarted. For example, if the Web.config file is changed, the application is restarted and all application state is lost unless
    application state values have been written to a non-volatile storage medium such as a database.
   Scalability Application state is not shared among multiple servers serving the same application, as in a Web farm, or
    among multiple worker processes serving the same application on the same server, as in a Web garden. Your application
    therefore cannot rely on application state containing the same data for application state across different servers or
    processes. If your application will run in multi-processor or multi-server environments, consider using a more scalable
    option, such as a database, for data that must preserve fidelity across the application.
   Concurrency Application state is free-threaded, which means that application state data can be accessed simultaneously
    by many threads. Therefore, it is important to ensure that when you update application state data, you do so in a thread-
    safe manner by including built-in synchronization support. You can use the Lock and UnLock methods to ensure data
    integrity by locking the data for writing by only one source at a time. You can also reduce the likelihood of concurrency
    problems by initializing application state values in the Application_Start method in the Global.asax file.

    ASP.NET Profile Properties Overview
    In many applications, you want to store and use information that is unique to a user. When a user visits your site, you can
    use the information you have stored to present the user with a personalized version of your Web application. Personalizing
    an application requires a number of elements: you must store the information using a unique user identifier, be able to
    recognize users when they visit again, and then fetch the user information as needed. To simplify your applications, you
    can use the ASP.NET profile feature, which can perform all of these tasks for you.
    The ASP.NET profile feature associates information with an individual user and stores the information in a persistent
    format. Profiles allow you to manage user information without requiring you to create and maintain your own database. In
    addition, the ASP.NET profile feature makes the user information available using a strongly typed API that you can access
    from anywhere in your application.
    You can store objects of any type using profiles. The profile feature provides a generic storage feature that allows you to
    define and maintain almost any kind of data while still making the data available in a type-safe manner.
    How ASP.NET Profiles Work
    To use profiles, you first enable profiles by modifying the configuration file for your ASP.NET Web application. As part of
    the configuration, you specify a profile provider, which is the underlying class that performs the low-level tasks of storing
    and retrieving profile data. You can use the profile provider included with the .NET Framework, which stores profile data in
    SQL Server, or you can create and use your own profile provider as described in the topic Implementing a Profile Provider.
    You can specify an instance of the SqlProfileProvider that connects to a database of your choosing, or you can use the
    default instance of the SqlProfileProvider that stores profile data on the local Web server.You configure the profile feature
    by defining a list of properties whose values you want to maintain. For example, you might want to store the user‟s postal
    code so that your application can offer region-specific information, such as weather reports. In the configuration file, you
    would define a profile property named PostalCode. The profile section of the configuration file might look like the
    following:Copy<profile> <properties> <add /> </properties></profile>
    When your application runs, ASP.NET creates a ProfileCommon class, which is a dynamically generated class that inherits
    the ProfileBase class. The dynamic ProfileCommon class includes properties created from the profile property definitions
    you specify in your application configuration. An instance of this dynamic ProfileCommon class is then set as the value of
    theProfile property of the current HttpContext and is available to pages in your application.
    In your application, you collect the value or values you want to store and assign them to the profile properties you have
    defined. For example, your application‘s home page might contain a text box that prompts the user to enter a postal code.
When the user enters a postal code, you set a Profileproperty to store the value for the current user, as in the following
example:
Profile.PostalCode = txtPostalCode.Text;
When you set a value for Profile.PostalCode, the value is automatically stored for the current user. You do not need to
write any code to determine who the current user is or explicitly store the value in a database���the profile feature
performs these tasks for you.
When you want to use the value, you can get it in much the same way that you set it. For example, the following code
example shows how to call an imaginary function named GetWeatherInfo, passing it the current user‘s postal code as
stored in a profile:
weatherInfo = GetWeatherInfo( Profile.PostalCode );
You do not need to explicitly determine who the user is or perform any database lookups. Simply getting the property
value out of a profile causes ASP.NET to perform the necessary actions to identify the current user and look up the value in
the persistent profile store.
State Management in ASP.NetIn general,
Webapplications are stateless i.e. the objects
wont persist its state accross request to the web
application. In other words, the State or Cache
Management is nothing but the way to storing
the data in Client-Side and in Server-Side using
pretty small memory to maintain its state.There
are two major categories of the above :1.
Server-Side State Management2.         Client-Side
State ManagementMoving forward, we will see
how State Management is done in ASP.Net
application.
Server-Side State ManagementSession State: Its nothing but defined as a period of
time shared between the web application and user. Every user has individual
session. Items/Objects can be placed into the Session which would only define         Recent
these objects for that user. Session contains key variables which help to identify Articles
the related values. This can be thought of as a hash table. Each user would           Disable
represent a different key node in the hash identifying unique values. The Session Public
variables will be clear by the application which can clear it, as well as through the holidays in
timeout property in the web config file. Usually the timeout is 20 minutes by         ASP.Net
default.Session Variables are stored on the server, can hold any type of data         Calendar
including references, they are similar to global variables in a windows application Control Poste
and use HTTP cookies to store a key with which to locate user’s session               d on
variables.The collection of session variables is indexed by the name of the           7/30/2010 @
variable or by an integer index. Session variables are created by referring to the 7:37 AM
session variable by name. You do not have to declare a session variable or            By Bala
explicitly add it to the collection.Lets get it cleared from following                Murugan
example:Session[“firstName”] = “Gaurav” //User’s first                                How to Pass
nameSession[“lastName”] = “Arora” //User’s last name// Clear the session              Values from
variableSession[“FirstName”] = null;//Clear all Session                               One Page to
variablesSession.Abandon(); InProc—Stores Session state in the same process as Another in
the ASP.NET process [aspnet_wp.exe].StateServer—Stores Session state in a             ASP.Net? Po
Windows NT process, which is distinct from the ASP.NET                                sted on
process[aspnet_state.exe].SQLServer—Stores Session state in a SQL Server              7/24/2010 @
database.Both in StateServer and SQLServer options, we need to ensure that the 1:31 AM
objects we cache are serializable as data storages are out-of-process systems. Both By Bala
these options have impact on the application performance as data retrieval and
saving operations take more time when compared to the InProc option. So based                                   Murugan
on our application requirement we should choose the option that best suits our                                  Using
requirement.Note:By default, ASP.NET session state is enabled for all ASP.NET                                   ADRotator
applications.ASP.NET application object                                                                         Control in
ASP.NET provides an object called Application object to store data that is accessible to all user requests. ASP.Net-
The life span of this object is tied to the application and it is re-created every time the application starts.
Unlike ASP.NETSession object this object is accessible to all user requests. Since this storage is created
                                                                                                                Part 2 Posted
and maintained in an application domain space, this should not be used for data storage in a web farm on 7/17/2010
scenario. This option is very useful to store data like the application metadata (CONFIG files data) that @ 1:21 AM
can be loaded to the Application object during application start up and can be used during the life of the
application without reloading it every time for each user request. But if there is a requirement to             BySatheesh
invalidate the cached data whenever there is any change to the CONFIG files while the application is            Babu B
running, this option should not be used as it doesn‘t provide any feature to expire the cached data. So in Pass Values
this case other options like the ASP.NET Cache object should be used, which is explained below.
Types of Cache –Dependencies                                                                                    from
When anyone add an item to cache, he/she can define the dependency relationships that can force that CodeBehind
item to be removed from the cache under specific activities of dependencies.                                    to JavaScript
For example: If the cache is dependent on file and when the file data changes you want the cache object
to be updated.                                                                                                  and From
Following are the difference dependencies:                                                                      JavaScript to
File Dependency :
                                                                                                                CodeBehind
Allows invalidating a specific cache item when a disk based file or files change.
object errorData;                                                                                               in
 //Load errorData from errors.xml                                                                               ASP.Net Post
 CacheDependency fileDependency =
                                                                                                                ed on
    new CacheDependency(Server.MapPath(―errors.xml‖));
 Cache.Insert(―ERROR_INFO‖, errorData, fileDependency);                                                         7/10/2010 @
Time based expiration :                                                                                         1:36 AM
Allows to invalidate a specific cache item depending on predefined time.
                                                                                                                BySatheesh
//Absolute Expiration
Cache.Insert(―EMP_NAME‖, ―Shubhabrata‖, null,                                                                   Babu B
          DateTime.Now.AddDays(1), Cache.NoSlidingExpiration);                                                  Using
//Sliding Expiration
Cache.Insert(―EMP_NAME‖, ―Shubhabrata‖, null,
                                                                                                                ADRotator
          Cache.NoAbsoluteExpiration, TimeSpan.FromSeconds(60));                                                Control in
Key dependency :                                                                                                ASP.Net-
Allows to invalidate a specific cache item depending when another cache item changes.
string[] relatedKeys = new string[1];
                                                                                                                Part 1 Posted
relatedKeys[0] = ―EMP_NUM‖;                                                                                     on 7/5/2010
CacheDependency keyDependency = new CacheDependency(null, relatedKeys);                                         @ 1:13 AM
Cache["EMP_NUM"] = 5435;
Cache.Insert(―EMP_NAME‖, ―Shubhabrata‖, keyDependency);
                                                                                                                By Satheesh
Cache.Insert(―EMP_ADDR‖, ―Bhubaneswar‖, keyDependency);                                                         Babu B
Cache.Insert(―EMP_SAL‖, ―5555USD‖, keyDependency);
.NET remoting
You might be thinking how .NET remoting can be used for data caching? The same question came to my
mind when I heard about it for the first time. As you know the .NET remoting singleton object shares
the same instance with multiple clients so singleton objects can be used to store and share data
between different client invocations. Since .NET remoting can be used outside the process and machine,
this option is very useful when we want to cache data and share it across servers and users particularly
in a web farm scenario. In this approach we can store the data as member variables of singleton
remoting object and provide methods to read and save data. But while implementing this we need to
ensure that the remoting object used as cache is not destroyed by the garbage collector. For that we will
have to set the remoting cache object‘s lease period to infinite so that the lease period never times out.
We can do that by overriding the InitializeLifetimeService method of MarshalByRefObject and
return null from this method. But the only issue with this approach is performance. As the analysis says
the performance is very poor in this approach when compared to other approaches. Anyway it is up to
the application designers/developers to analyze different options and use the best one that suits the
requirement.
Memory-mapped files
You all know what a memory-mapped file is. It is basically about mapping a file on disk to a specific
range of addresses in the application‘s process address space. This option allows different processes to
use the same data by increasing the application performance. As using memory-mapped file is not very
popular among .NET developers, I would personally not suggest this approach as implementing this
involves a lot of complexities and also .NET Framework doesn‘t support this. But if anyone is very much
interested in using this approach then they will have to develop their own custom solution as per their
own requirement.
Static variables
We use static variables for storing data or objects globally so that it can be accessed during the life of
the application. Similarly, in ASP.NET we can use static objects for caching data and we can also provide
methods to retrieve and save data to the cache. As static variables are stored in the process area,
performance wise it is faster. But since it is very difficult to implement expiration policies and
dependencies incase of static variables, I generally prefer ASP.NET cache object over this option.
Another problem is that the custom static cache object has to be thread-safe which has to be
implemented carefully.
Example:
public class CustomCache
{
   //Synchronized to implement thread-safe
   static Hashtable _myCache =
          Hashtable.Synchronized(new Hashtable());
      public static object GetData(object key) {
      return _myCache[key];
   }
   public static void SetData(object key, object val)
   {
      _myCache[key] = val;
   }
}


 Client-Side State ManagementCookiesCookie is a very familiar term in web
development environment. Cookie is a client-side storage that is sent to the server
for each request and also received as response back from the server. Because of its
size limitation (4096 bytes) it should be used for storing small amount of data.
Expiration policies can be set for cookies to invalidate the items after a certain
period of time. The following example shows how Cookie can be used in an
ASP.NET application:if (this.Request.Cookies["MY_NAME"] == null) {
this.Response.Cookies.Add(new
HttpCookie(“MY_NAME”,                                 “Shubhabrata
Mohanty”));}else{
this.Response.Write(this.Request.Cookies["MY_NAME"].Value);}ViewStateASP
.NET ViewState is a new concept. Here the data related to the pages and controls
are stored in ViewState which retains the values across multiple requests to the
server. If you remember correctly, in VB-ASP applications we used to store data
across multiple requests using hidden fields. ViewState is actually implemented
internally as hidden fields in ASP.NET but here the data is hashed to improve
security as against hidden fields. To see how ViewState is implemented, you can
view the source of the page in which ViewState is used in the Internet
browser. ViewState should not be used to store large amounts of data as it is
passed to the server for each requestprotected void Page_Load(object sender,
EventArgs e) { if (this.ViewState["MY_NAME"] == null) {
this.ViewState["MY_NAME"] = “Shuby”;
    }
       //txtName is a TextBox control
    this.txtName.Text = this.ViewState["MY_NAME"].ToString();
}
Hidden fields
Hidden fields are very popular among VB-ASP web developers. Hidden field is similar to any other
control in a page but the visible state of this control is always false. Like ViewState we should not use it
for storing large amounts of data.
Note:Similarly hidden frames can be used to cache data in the client side. But please note that hidden
frames are not supported by all Internet browsers.
<!–In ASP.NET–>
<asp:HiddenField Value=‖Shuby‖ runat=‖server‖ />
<!–In HTML–>
<input value=‖Shuby‖ />

Insert Image & Retrive Image From Database
Default.aspx
<form id=”form1″ runat=”server”>
   <div>
      emp name
      <asp:TextBox ID=”TextBox1″ runat=”server”></asp:TextBox>
      <br />
      <br />
      emp image&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      <asp:FileUpload ID=”FileUpload1″ runat=”server” />
      <br />
      <br />
      <asp:Button ID=”Button1″ runat=”server” onclick=”Button1_Click” Text=”Add”
          Width=”100px” />
      <asp:Button ID=”Button2″ runat=”server” onclick=”Button2_Click”
          Text=”Display” />
      <asp:Image ID=”Image1″ runat=”server” Width=”677px” />
      <br />
    </div>
</form>
Default.aspx.cs
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlCommand cmd;
   SqlDataReader rd;
   public _Default()
   {
      con = new SqlConnection(“initial catalog=employee;integrated security=yes”);
      con.Open();
   }
   protected void Page_Load(object sender, EventArgs e)
   {
   }
   protected void Button1_Click(object sender, EventArgs e)
   {
      string fn =FileUpload1.FileName;
      FileUpload1.SaveAs(Server.MapPath(@”image/”) + FileUpload1.FileName);
      string path=”~/image/”+fn;
      cmd = new SqlCommand(“insert into emp values(„”+TextBox1.Text+”„,‟”+path+”„)”,con);
      int t = cmd.ExecuteNonQuery();
      if (t>0)
      {
          Response.Write(“record inserted”);
      }
   }
   protected void Button2_Click(object sender, EventArgs e)
   {
      cmd = new SqlCommand(“select empimage from emp”, con);
      rd = cmd.ExecuteReader();
      while (rd.Read())
      {
          Image1.ImageUrl = rd[0].ToString();
      }
   }
}
insert record throgh gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ ―http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd―>
<html xmlns=‖http://www.w3.org/1999/xhtml―>
<head runat=‖server‖>
   <title></title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ ShowFooter=‖True‖ AutoGenerateColumns=‖false‖
         runat=‖server‖ BackColor=‖#DEBA84″ BorderColor=‖#DEBA84″ BorderStyle=‖None‖
         BorderWidth=‖1px‖ CellPadding=‖3″ CellSpacing=‖2″>
         <RowStyle BackColor=‖#FFF7E7″ ForeColor=‖#8C4510″ />
      <Columns>
      <asp:TemplateField>
      <HeaderTemplate>Emp Id</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# bind(―EmpId‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
      <asp:TextBox ID=‖txtEmpId‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
       <asp:TemplateField>
      <HeaderTemplate>Emp Name</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# bind(―EmpName‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
      <asp:TextBox ID=‖txtEmpName‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
 <asp:TemplateField>
      <HeaderTemplate>Emp Salary</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# bind(―EmpSalary‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
      <asp:TextBox ID=‖txtEmpSalary‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
       <asp:TemplateField>
      <HeaderTemplate>Operation</HeaderTemplate>

     <FooterTemplate>
        <asp:Button ID=‖btnAdd‖ runat=‖server‖ OnClick=‖AddRecord‖ Text=‖Add‖ />
     </FooterTemplate>
     </asp:TemplateField>
     </Columns>
        <FooterStyle BackColor=‖#F7DFB5″ ForeColor=‖#8C4510″ />
        <PagerStyle ForeColor=‖#8C4510″ HorizontalAlign=‖Center‖ />
        <SelectedRowStyle BackColor=‖#738A9C‖ Font-Bold=‖True‖ ForeColor=‖White‖ />
        <HeaderStyle BackColor=‖#A55129″ Font-Bold=‖True‖ ForeColor=‖White‖ />
     </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Data;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlCommand cmd;
   SqlDataReader rd;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      con.Open();
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fill();
      }
   }
   void fill()
   {
      con.Close();
      con.Open();
      cmd=new SqlCommand (―select * from Employee‖,con);
      rd = cmd.ExecuteReader();
      GridView1.DataSource = rd;
      GridView1.DataBind();

     rd.Close();



   }
   protected void AddRecord(object sender, EventArgs e)
   {
      TextBox txtEmpId =GridView1.FooterRow.FindControl(―txtEmpId‖) as TextBox;
      TextBox txtEmpName = GridView1.FooterRow.FindControl(―txtEmpName‖) as TextBox;
      TextBox txtEmpSalary = GridView1.FooterRow.FindControl(―txtEmpSalary‖) as TextBox;
      con.Close();
      con.Open();
      cmd = new SqlCommand(―insert into Employee values(‖ + Convert.ToInt32(txtEmpId.Text) + ―,‘‖ +
txtEmpName.Text + ―‗,‖ + Convert.ToDecimal(txtEmpSalary.Text) + ―)‖, con);
      int t=cmd.ExecuteNonQuery();
      if (t>0)
      {
          fill();
       }

   }
}
Manipulation(Insert, Update, Delete) in asp.net
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ ―http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd―>
<html xmlns=‖http://www.w3.org/1999/xhtml―>
<head runat=‖server‖>
   <title></title>
   <style type=‖text/css‖>
     .style1
     {
        width: 100%;
     }
  </style>
</head>
<body>
  <form id=‖form1″ runat=‖server‖>
  <table class=‖style1″>
     <tr>
        <td>
           Emp Id</td>
        <td>
           <asp:TextBox ID=‖txtEmpId‖ runat=‖server‖></asp:TextBox>
        </td>
     </tr>
     <tr>
        <td>
           Emp Name</td>
        <td>
           <asp:TextBox ID=‖txtEmpName‖ runat=‖server‖></asp:TextBox>
        </td>
     </tr>
     <tr>
        <td>
           Emp Salary</td>
        <td>
           <asp:TextBox ID=‖txtEmpSalary‖ runat=‖server‖></asp:TextBox>
        </td>
     </tr>
     <tr>
        <td colspan=‖2″>
           <br />
           <br />
           <asp:Button ID=‖btnDisplay‖ runat=‖server‖ onclick=‖btnDisplay_Click‖
             Text=‖Display‖ />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
           <asp:Button ID=‖btnNext‖ runat=‖server‖ onclick=‖btnNext_Click‖ Text=‖Next‖ />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
           <asp:Button ID=‖btnPrev‖ runat=‖server‖ onclick=‖btnPrev_Click‖ Text=‖Prev‖ />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
           <asp:Button ID=‖btnInsert‖ runat=‖server‖ onclick=‖btnInsert_Click‖
             Text=‖Insert‖ />
&nbsp;&nbsp;&nbsp;&nbsp;
           <asp:Button ID=‖btnUpdate‖ runat=‖server‖ onclick=‖btnUpdate_Click‖
             Text=‖Update‖ />
&nbsp;&nbsp;&nbsp;
           <asp:Button ID=‖btnDelete‖ runat=‖server‖ onclick=‖btnDelete_Click‖
             Text=‖Delete‖ />
        </td>
     </tr>
  </table>
  <div>

   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   static int counter;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from employee‖, con);
      adap.Fill(ds, ―employee‖);
      bui = new SqlCommandBuilder(adap);

  }
   protected void Page_Load(object sender, EventArgs e)
   {

  }

  protected void btnDisplay_Click(object sender, EventArgs e)
  {
     txtEmpId.Text = ds.Tables["Employee"].Rows[0][0].ToString();
     txtEmpName.Text = ds.Tables["Employee"].Rows[0][1].ToString();
     txtEmpSalary.Text = ds.Tables["Employee"].Rows[0][2].ToString();
  }
  protected void btnNext_Click(object sender, EventArgs e)
  {
     int count = ds.Tables["Employee"].Rows.Count;
     counter++;
     if (counter<count)
     {
         txtEmpId.Text = ds.Tables["Employee"].Rows[counter][0].ToString();
         txtEmpName.Text = ds.Tables["Employee"].Rows[counter][1].ToString();
         txtEmpSalary.Text = ds.Tables["Employee"].Rows[counter][2].ToString();

      }
      else
      {

          Response.Write(―Record Not Found‖);
      }
  }
  protected void btnPrev_Click(object sender, EventArgs e)
  {
     int count = ds.Tables["Employee"].Rows.Count;
     counter–;
     if (counter < count)
     {
         txtEmpId.Text = ds.Tables["Employee"].Rows[counter][0].ToString();
         txtEmpName.Text = ds.Tables["Employee"].Rows[counter][1].ToString();
         txtEmpSalary.Text = ds.Tables["Employee"].Rows[counter][2].ToString();
     }
     else
     {
         Response.Write(―Record Not Found‖);
     }
   }
   protected void btnInsert_Click(object sender, EventArgs e)
   {
      adap.InsertCommand = bui.GetInsertCommand();
      DataRow dr=ds.Tables["Employee"].NewRow();
      dr[0] = Convert.ToInt32(txtEmpId.Text);
      dr[1] = txtEmpName.Text;
      dr[2] = Convert.ToDecimal(txtEmpSalary.Text);
      ds.Tables["Employee"].Rows.Add(dr);
      adap.Update(ds.Tables["Employee"]);
   }
   protected void btnUpdate_Click(object sender, EventArgs e)
   {
    adap.UpdateCommand = bui.GetUpdateCommand();
    DataRow[] dr = ds.Tables["Employee"].Select(―EmpId=‖+Convert.ToInt32(txtEmpId.Text)+‖");
    dr[0][1] = txtEmpName.Text;
    dr[0][2] = Convert.ToDecimal(txtEmpSalary.Text);
    adap.Update(ds.Tables["Employee"]);
   }
   protected void btnDelete_Click(object sender, EventArgs e)
   {
       adap.DeleteCommand = bui.GetDeleteCommand();
DataColumn[] dc = new DataColumn[1];
dc[0]=ds.Tables["Emp"].Columns["EmpId"];
ds.Tables["Emp"].PrimaryKey = dc;
DataRow dr= ds.Tables["Emp"].Rows.Find(Convert.ToInt32(txtEmpId.Text));
dr.Delete();
adap.Update(ds.Tables["Emp"]);
        }
}


display Record in Repeater
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ ―http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd―>
<html xmlns=‖http://www.w3.org/1999/xhtml―>
<head runat=‖server‖>
   <title></title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:Repeater ID=‖Repeater1″ runat=‖server‖>
      <HeaderTemplate>
      <table>
      <tr>
      <td style=‖width:100px;background-color:Gray;‖>Emp Id</td>
      <td style=‖width:100px;background-color:Gray;‖>Emp Name</td>
      <td style=‖width:100px;background-color:Gray;‖>Emp Salary</td>
      </tr>
      </table>
      </HeaderTemplate>
      <ItemTemplate>
      <table>
      <tr>
      <td style=‖width:100px;background-color:Gray;‖>
      <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# bind(―EmpId‖) %>‘>
      </asp:Label>
      </td>
      <td style=‖width:100px;background-color:Gray;‖>
      <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# bind(―EmpName‖) %>‘>
      </asp:Label>
      </td>
      <td style=‖width:100px;background-color:Gray;‖>
      <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# bind(―EmpSalary‖) %>‘>
      </asp:Label>
      </td>
      </tr>
      </table>
      </ItemTemplate>
      </asp:Repeater>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      fill();
   }
   void fill()
   {
      adap = new SqlDataAdapter(―select * from employee‖,con);
      adap.Fill(ds,‖Employee‖);
      Repeater1.DataSource = ds;
      Repeater1.DataBind();
   }
}
Deletion in Gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ ―http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd―>
<html xmlns=‖http://www.w3.org/1999/xhtml―>
<head runat=‖server‖>
   <title></title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ OnRowDeleting=‖deleterecord‖ AutoGenerateColumns=‖False‖ runat=‖server‖>
      <Columns>
      <asp:TemplateField HeaderText=‖Emp Id‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# bind(―EmpId‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
        <asp:TemplateField HeaderText=‖Emp Name‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# bind(―EmpName‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
        <asp:TemplateField HeaderText=‖Emp Salary‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# bind(―EmpSalary‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
        <asp:TemplateField HeaderText=‖Operation‖>
      <ItemTemplate>
      <asp:Button ID=‖btnDelete‖ runat=‖server‖ CommandName=‖Delete‖ Text=‖Delete‖ />
      </ItemTemplate>
      </asp:TemplateField>
      </Columns>
      </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Data;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from Employee‖, con);
      adap.Fill(ds, ―Employee‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fill();
      }
   }
   void fill()
   {

     GridView1.DataSource = ds;
     GridView1.DataBind();
  }
  protected void deleterecord(object sender, GridViewDeleteEventArgs e)
  {
     adap.DeleteCommand = bui.GetDeleteCommand();
    //DataColumn[] dc = new DataColumn[1];

    // Label lblEmpId =GridView1.Rows[e.RowIndex].FindControl(―lblEmpId‖) as Label;
    // DataRow dr= ds.Tables["Employee"].Rows.Find(Convert.ToInt32(lblEmpId.Text));
    // dr.Delete();
     ds.Tables["Employee"].Rows[e.RowIndex].Delete();
     adap.Update(ds.Tables["Employee"]);
     fill();
   }
}
updation in gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ <head runat=‖server‖>
   <title></title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
   <asp:GridView ID=‖g1″ OnRowUpdating=‖updateRecord‖ AutoGenerateColumns=‖false‖
OnRowCancelingEdit=‖cancelRecord‖ OnRowEditing=‖editRecord‖ runat=‖server‖>
   <Columns>
   <asp:TemplateField HeaderText=‖Emp Id‖>
   <ItemTemplate>
   <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# Bind(―EmpId‖) %>‘></asp:Label>
   </ItemTemplate>
   </asp:TemplateField>
   <asp:TemplateField HeaderText=‖Emp Name‖>
   <ItemTemplate>
   <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# Bind(―EmpName‖) %>‘></asp:Label>
   </ItemTemplate>
   <EditItemTemplate>
   <asp:TextBox ID=‖txtEmpName‖ runat=‖server‖ Text=‘<%# Bind(―EmpName‖) %>‘></asp:TextBox>
   </EditItemTemplate>
   </asp:TemplateField>
   <asp:TemplateField HeaderText=‖Emp Salary‖>
   <ItemTemplate>
   <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# Bind(―EmpSalary‖) %>‘></asp:Label>
   </ItemTemplate>
   <EditItemTemplate>
   <asp:TextBox ID=‖txtEmpSalary‖ runat=‖server‖ Text=‘<%# Bind(―EmpSalary‖) %>‘></asp:TextBox>
   </EditItemTemplate>
   </asp:TemplateField>
   <asp:TemplateField HeaderText=‖Operation‖>
   <ItemTemplate>
   <asp:Button ID=‖btnEdit‖ runat=‖server‖ CommandName=‖Edit‖ Text=‖Edit‖ />
   </ItemTemplate>
   <EditItemTemplate>
   <asp:Button ID=‖btnUpdate‖ CommandName=‖Update‖ runat=‖server‖ Text=‖Update‖ />
   <asp:Button ID=‖btnCancel‖ runat=‖server‖ CommandName=‖Cancel‖ Text=‖Cancel‖ />
   </EditItemTemplate>
   </asp:TemplateField>
   </Columns>
   </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from Employee‖, con);
      adap.Fill(ds, ―Employee‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fill();
      }
   }
   void fill()
   {

      g1.DataSource = ds;
      g1.DataBind();
  }
  protected void editRecord(object sender, GridViewEditEventArgs e)
  {
      g1.EditIndex = e.NewEditIndex;
      fill();
  }
  protected void cancelRecord(object sender, GridViewCancelEditEventArgs e)
  {
      g1.EditIndex = -1;
      fill();
  }
  protected void updateRecord(object sender, GridViewUpdateEventArgs e)
  {
      adap.UpdateCommand = bui.GetUpdateCommand();
      Label lblEmpId =g1.Rows[e.RowIndex].FindControl(―lblEmpId‖) as Label;
     TextBox txtEmpName =g1.Rows[e.RowIndex].FindControl(―txtEmpName‖) as TextBox;
     TextBox txtEmpSalary = g1.Rows[e.RowIndex].FindControl(―txtEmpSalary‖) as TextBox;
    DataRow[] dr= ds.Tables["Employee"].Select(―EmpId=‖+Convert.ToInt32(lblEmpId.Text)+‖");
    dr[0]["EmpName"] = txtEmpName.Text;
    dr[0]["EmpSalary"] = Convert.ToDecimal(txtEmpSalary.Text);
  int temp= adap.Update(ds.Tables["Employee"]);
  if (temp>0)
  {
      g1.EditIndex = -1;
      fill();

  }
   }
}
record show in Datalist
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<!DOCTYPE html PUBLIC ―-//W3C//DTD XHTML 1.0 Transitional//EN‖ ―http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd―>
<html xmlns=‖http://www.w3.org/1999/xhtml―>
<head runat=‖server‖>
   <title></title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
   <asp:DataList ID=‖d1″ runat=‖server‖ RepeatColumns=‖3″ >

  <ItemTemplate>
  <table>
  <tr>
  <td style=‖width:100px;‖>
  <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# bind(―EmpId‖) %>‘></asp:Label>
  </td></tr>
  <tr>
  <td style=‖width:100px;‖><asp:Label ID=‖Label1″ runat=‖server‖ Text=‘<%# bind(―EmpName‖)
%>‘></asp:Label></td></tr>
 <tr> <td style=‖width:100px;‖><asp:Label ID=‖Label2″ runat=‖server‖ Text=‘<%# bind(―EmpSalary‖)
%>‘></asp:Label></td>
  </tr>
  </table>
  </ItemTemplate>
  </asp:DataList>

   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      fill();
   }
   void fill()
   {
     DataList d;
     Repeater r1;
     adap = new SqlDataAdapter(―select * from Employee‖,con);
     adap.Fill(ds,‖Employee‖);
     d1.DataSource = ds;
     d1.DataBind();



   }
}
Difference b/w Repeater,Data List & Grid View :-
Concept Repeater Data List Grid View
Base Class Control Web Control Web Control
Default Output No No Yes
Manipulation No No Yes
Paging No no Yes
Auto Formatting No Yes Yes
Repeat Column No Yes No
Sorting No No Yes
ajax
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>

<head runat=‖server‖>
  <title></title>
  <script language=‖javascript‖ type=‖text/javascript‖ >
     function chk() {
        var r = document.getElementById(―TextBox1″).value;
        if (r < 60) {
            alert(―enter above 60″);
            return false;
        }
        else {
            return true;
        }
     }
  </script>
</head>
<body>
  <form id=‖form1″ runat=‖server‖>
  <asp:ScriptManager ID=‖ScriptManager1″ runat=‖server‖>
  </asp:ScriptManager>
  <asp:UpdatePanel ID=‖up1″ runat=‖server‖>
  <ContentTemplate>

  <div>
    <asp:TextBox ID=‖TextBox1″ runat=‖server‖></asp:TextBox>

  <asp:Button ID=‖btnfirst‖ runat=‖server‖ Text=‖first‖ onclick=‖btnfirst_Click‖ />
    <br />
    <br />
    <br />
  </div>
  </ContentTemplate>
  <Triggers>
  <asp:AsyncPostBackTrigger ControlID=‖btnfirst‖ EventName=‖Click‖ />
  </Triggers>
  </asp:UpdatePanel>
  <div>
  <asp:TextBox ID=‖TextBox2″ runat=‖server‖></asp:TextBox>

  <asp:Button ID=‖btnsecond‖ runat=‖server‖ Text=‖second‖
       onclick=‖btnsecond_Click‖ />
  </div>

   </form>
</body>
</html>
.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
   protected void Page_Load(object sender, EventArgs e)
   {
      TextBox1.Text = System.DateTime.Now.Second.ToString();
      TextBox2.Text = System.DateTime.Now.Second.ToString();

  }
  protected void Button1_Click(object sender, EventArgs e)
  {
     Response.Write(―cac‖);
  }
  protected void btnfirst_Click(object sender, EventArgs e)
  {
     TextBox1.Text = System.DateTime.Now.Second.ToString();

  }
  protected void btnsecond_Click(object sender, EventArgs e)
  {

      TextBox2.Text = System.DateTime.Now.Second.ToString();
  }
}
check all in gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ AutoGenerateColumns=‖false‖ runat=‖server‖>
      <Columns>
      <asp:TemplateField >
      <HeaderTemplate>
      <asp:Button ID=‖btnDelete‖ OnClick=‖deleterecord‖ Text=‖Delete‖ runat=‖server‖ />
      <asp:CheckBox ID=‖chkAll‖ OnCheckedChanged=‖checkallrows‖ AutoPostBack=‖true‖ runat=‖server‖ />
      </HeaderTemplate>
      <ItemTemplate>
      <asp:CheckBox ID=‖chkRow‖ runat=‖server‖ />
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Emp Id‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpId‖ runat=‖server‖ Text=‘<%# bind(―Emp_Id‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Emp Name‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# bind(―Emp_Name‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Emp Salary‖>
      <ItemTemplate>
      <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# bind(―Emp_Salary‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      </Columns>
      </asp:GridView>
   </div>
   </form>
</body>
</html>
.aspx.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=abhi;integrated security=yes‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from abhinavsir‖,con);
      adap.Fill(ds,‖Emp‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fill();
      }
   }
   void fill()
   {
      GridView1.DataSource = ds;
      GridView1.DataBind();
   }
   protected void checkallrows(object sender, EventArgs e)
   {
     CheckBox chkall =GridView1.HeaderRow.FindControl(―chkall‖) as CheckBox;

   for (int i = 0; i < GridView1.Rows.Count; i++)
   {
      CheckBox chkrow = GridView1.Rows[i].FindControl(―chkrow‖) as CheckBox;
      if (chkall.Checked==true)
        {
           chkrow.Checked = true;
        }
        else
        {
           chkrow.Checked = false;
        }

   }

  }
  protected void deleterecord(object sender, EventArgs e)
  {

       for (int i = 0; i < GridView1.Rows.Count; i++)
       {
         CheckBox chkrow = GridView1.Rows[i].FindControl(―chkrow‖) as CheckBox;
         if (chkrow.Checked==true)
         {
             adap.DeleteCommand = bui.GetDeleteCommand();
             ds.Tables["Emp"].Rows[i].Delete();



         }
       }
       int t = adap.Update(ds.Tables["Emp"]);
       fill();
   }
}
Record insert & Delete in gridview though disconnected mode
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView OnRowDeleting=‖DeleteRecord‖ AutoGenerateColumns=‖False‖ ShowFooter=‖True‖ ID=‖GridView1″
         runat=‖server‖>
      <Columns>
      <asp:TemplateField>
      <HeaderTemplate>Product No</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductNo‖ runat=‖server‖ Text=‘<%# bind(―Product_No‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
         <asp:TextBox ID=‖txtProductNo‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
      <asp:TemplateField>
      <HeaderTemplate>Product Name</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductName‖ runat=‖server‖ Text=‘<%# bind(―Product_Name‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
         <asp:TextBox ID=‖txtProductName‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
      <asp:TemplateField>
      <HeaderTemplate>Product Price</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductPrice‖ runat=‖server‖ Text=‘<%# bind(―Product_Price‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
          <asp:TextBox ID=‖txtProductPrice‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
      <asp:TemplateField>
      <HeaderTemplate>Operation</HeaderTemplate>
      <ItemTemplate>
      <asp:Button ID=‖btnDelete‖ runat=‖server‖ CommandName=‖Delete‖ Text=‖Delete‖ />
      </ItemTemplate>
       <FooterTemplate>
           <asp:Button ID=‖btnSave‖ runat=‖server‖ OnClick=‖saverecord‖ Text=‖Save‖ />
      </FooterTemplate>
      </asp:TemplateField>
      </Columns>
      </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=ritu;uid=sa;pwd=sa‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from Product‖,con);
      adap.Fill(ds,‖Prod‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fillrecord();
      }
   }
   void fillrecord()
   {
      GridView1.DataSource = ds;
      GridView1.DataBind();
   }
   protected void saverecord(object sender, EventArgs e)
   {
      adap.InsertCommand = bui.GetInsertCommand();
    TextBox txtProductNo =GridView1.FooterRow.FindControl(―txtProductNo‖) as TextBox;
    TextBox txtProductName = GridView1.FooterRow.FindControl(―txtProductName‖) as TextBox;
    TextBox txtProductPrice = GridView1.FooterRow.FindControl(―txtProductPrice‖) as TextBox;
   DataRow dr =ds.Tables["Prod"].NewRow();
   dr[0] = Convert.ToInt32(txtProductNo.Text);
   dr[1] = txtProductName.Text;
   dr[2] =Convert.ToDecimal(txtProductPrice.Text);
   ds.Tables["Prod"].Rows.Add(dr);
   int t=adap.Update(ds.Tables["Prod"]);
   if (t>0)
   {
       fillrecord();
   }
  }
  protected void DeleteRecord(object sender, GridViewDeleteEventArgs e)
  {
     adap.DeleteCommand = bui.GetDeleteCommand();
    ds.Tables["Prod"].Rows[e.RowIndex].Delete();
    adap.Update(ds.Tables["Prod"]);
       fillrecord();

   }
}
Record insert & Delete in gridview though disconnected mode
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView OnRowDeleting=‖DeleteRecord‖ AutoGenerateColumns=‖False‖ ShowFooter=‖True‖ ID=‖GridView1″
         runat=‖server‖>
      <Columns>
      <asp:TemplateField>
      <HeaderTemplate>Product No</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductNo‖ runat=‖server‖ Text=‘<%# bind(―Product_No‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
         <asp:TextBox ID=‖txtProductNo‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
      <asp:TemplateField>
      <HeaderTemplate>Product Name</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductName‖ runat=‖server‖ Text=‘<%# bind(―Product_Name‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
         <asp:TextBox ID=‖txtProductName‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
      <asp:TemplateField>
      <HeaderTemplate>Product Price</HeaderTemplate>
      <ItemTemplate>
      <asp:Label ID=‖lblProductPrice‖ runat=‖server‖ Text=‘<%# bind(―Product_Price‖) %>‘></asp:Label>
      </ItemTemplate>
      <FooterTemplate>
         <asp:TextBox ID=‖txtProductPrice‖ runat=‖server‖></asp:TextBox>
      </FooterTemplate>
      </asp:TemplateField>
       <asp:TemplateField>
       <HeaderTemplate>Operation</HeaderTemplate>
       <ItemTemplate>
       <asp:Button ID=‖btnDelete‖ runat=‖server‖ CommandName=‖Delete‖ Text=‖Delete‖ />
       </ItemTemplate>
        <FooterTemplate>
            <asp:Button ID=‖btnSave‖ runat=‖server‖ OnClick=‖saverecord‖ Text=‖Save‖ />
       </FooterTemplate>
       </asp:TemplateField>
       </Columns>
       </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
       con = new SqlConnection(―initial catalog=ritu;uid=sa;pwd=sa‖);
       ds = new DataSet();
       adap = new SqlDataAdapter(―select * from Product‖,con);
       adap.Fill(ds,‖Prod‖);
       bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
       if (!IsPostBack)
       {
           fillrecord();
       }
   }
   void fillrecord()
   {
       GridView1.DataSource = ds;
       GridView1.DataBind();
   }
   protected void saverecord(object sender, EventArgs e)
   {
       adap.InsertCommand = bui.GetInsertCommand();
      TextBox txtProductNo =GridView1.FooterRow.FindControl(―txtProductNo‖) as TextBox;
      TextBox txtProductName = GridView1.FooterRow.FindControl(―txtProductName‖) as TextBox;
      TextBox txtProductPrice = GridView1.FooterRow.FindControl(―txtProductPrice‖) as TextBox;
     DataRow dr =ds.Tables["Prod"].NewRow();
     dr[0] = Convert.ToInt32(txtProductNo.Text);
     dr[1] = txtProductName.Text;
        dr[2] =Convert.ToDecimal(txtProductPrice.Text);
        ds.Tables["Prod"].Rows.Add(dr);
        int t=adap.Update(ds.Tables["Prod"]);
        if (t>0)
        {
            fillrecord();
        }
    }
    protected void DeleteRecord(object sender, GridViewDeleteEventArgs e)
    {
       adap.DeleteCommand = bui.GetDeleteCommand();
      ds.Tables["Prod"].Rows[e.RowIndex].Delete();
      adap.Update(ds.Tables["Prod"]);
         fillrecord();

    }
}

 .updation through Gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ OnRowUpdating=‖updaterecord‖ OnRowCancelingEdit=‖cancelrecord‖
OnRowEditing=‖editrecord‖ AutoGenerateColumns=‖false‖ runat=‖server‖>
      <Columns>
      <asp:TemplateField HeaderText=‖Product No‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductNo‖ runat=‖server‖ Text=‘<%# bind(―Product_no‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Product Name‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductName‖ runat=‖server‖ Text=‘<%# bind(―Product_name‖) %>‘></asp:Label>
      </ItemTemplate>
      <EditItemTemplate>
      <asp:TextBox ID=‖txtProductName‖ runat=‖server‖ Text=‘<%# bind(―Product_name‖) %>‘></asp:TextBox>
      </EditItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Product Price‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductPrice‖ runat=‖server‖ Text=‘<%# bind(―Product_Price‖) %>‘></asp:Label>
      </ItemTemplate>
      <EditItemTemplate>
      <asp:TextBox ID=‖txtProductPrice‖ runat=‖server‖ Text=‘<%# bind(―Product_Price‖) %>‘></asp:TextBox>
      </EditItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Operation‖>
      <ItemTemplate>
         <asp:Button ID=‖btnEdit‖ CommandName=‖Edit‖ runat=‖server‖ Text=‖Edit‖ />
      </ItemTemplate>
      <EditItemTemplate>
         <asp:Button ID=‖btnUpdate‖ runat=‖server‖ Text=‖Update‖ CommandName=‖update‖ />
         <asp:Button ID=‖btnCancel‖ runat=‖server‖ Text=‖Cancel‖ CommandName=‖cancel‖ />
      </EditItemTemplate>
      </asp:TemplateField>
      </Columns>
      </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=ritu;uid=sa;pwd=sa‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from product‖,con);
      adap.Fill(ds,‖product‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fillrecord();
      }
   }
   void fillrecord()
   {
      GridView1.DataSource = ds;
      GridView1.DataBind();

  }
  protected void editrecord(object sender, GridViewEditEventArgs e)
  {
     GridView1.EditIndex = e.NewEditIndex;
     fillrecord();
  }
  protected void cancelrecord(object sender, GridViewCancelEditEventArgs e)
  {
     GridView1.EditIndex = -1;
     fillrecord();
  }
  protected void updaterecord(object sender, GridViewUpdateEventArgs e)
  {
     adap.UpdateCommand = bui.GetUpdateCommand();
     Label lblProductNo = GridView1.Rows[e.RowIndex].FindControl(―lblProductNo‖) as Label;
     TextBox txtProductName = GridView1.Rows[e.RowIndex].FindControl(―txtProductName‖) as TextBox;
     TextBox txtProductPrice = GridView1.Rows[e.RowIndex].FindControl(―txtProductPrice‖) as TextBox;
    DataRow[] dr =ds.Tables["Product"].Select(―Product_No=‖+Convert.ToInt32(lblProductNo.Text)+‖");
    dr[0][1] = txtProductName.Text;
    dr[0][2] =Convert.ToDecimal(txtProductPrice.Text);
   int t =adap.Update(ds,‖Product‖);
   if (t>0)
   {
       GridView1.EditIndex = -1;
       fillrecord();
   }
  }
}
Check All Through Gridview
.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ AutoGenerateColumns=‖false‖ runat=‖server‖>
      <Columns>
      <asp:TemplateField >
      <HeaderTemplate>
      <asp:Button ID=‖btnDelete‖ OnClick=‖deleterecord‖ Text=‖Delete‖ runat=‖server‖ />
      <asp:CheckBox Text=‖Check All‖ OnCheckedChanged=‖checkRows‖ AutoPostBack=‖true‖ ID=‖chkAll‖
runat=‖server‖ />
      </HeaderTemplate>
      <ItemTemplate>
      <asp:CheckBox ID=‖chkRow‖ runat=‖server‖ />
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Product No‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductNo‖ runat=‖server‖ Text=‘<%# bind(―Product_no‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Product Name‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductName‖ runat=‖server‖ Text=‘<%# bind(―Product_name‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>
      <asp:TemplateField HeaderText=‖Product Price‖>
      <ItemTemplate>
      <asp:Label ID=‖lblProductPrice‖ runat=‖server‖ Text=‘<%# bind(―Product_Price‖) %>‘></asp:Label>
      </ItemTemplate>
      </asp:TemplateField>

     </Columns>



     </asp:GridView>
   </div>
   </form>
</body>
</html>
.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlDataAdapter adap;
   DataSet ds;
   SqlCommandBuilder bui;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=ritu;uid=sa;pwd=sa‖);
      ds = new DataSet();
      adap = new SqlDataAdapter(―select * from product‖, con);
      adap.Fill(ds, ―product‖);
      bui = new SqlCommandBuilder(adap);
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fillrecord();
      }
   }
   void fillrecord()
   {
      GridView1.DataSource = ds;
      GridView1.DataBind();
   }
   protected void checkRows(object sender, EventArgs e)
   {
      CheckBox chkall = GridView1.HeaderRow.FindControl(―chkAll‖) as CheckBox;
      for (int i = 0; i < GridView1.Rows.Count; i++)
      {
          CheckBox chkrow = GridView1.Rows[i].FindControl(―chkrow‖) as CheckBox;
          if (chkall.Checked==true)
          {
               chkrow.Checked = true;
          }
          else
          {
               chkrow.Checked = false;
          }
      }
   }
   protected void deleterecord(object sender, EventArgs e)
   {
      adap.DeleteCommand = bui.GetDeleteCommand();
      for (int i = 0; i < GridView1.Rows.Count; i++)
      {
          CheckBox chkrow = GridView1.Rows[i].FindControl(―chkrow‖) as CheckBox;
          if (chkrow.Checked == true)
          {
               ds.Tables["Product"].Rows[i].Delete();
          }

     }
    int t =adap.Update(ds.Tables["Product"]);
    if (t>0)
    {
            fillrecord();
        }
    }
}




using
System;
using
System.Collections.Generic;
using
System.Linq;
using
System.Web;
using
System.Web.UI;
using
System.Web.UI.WebControls;
using
System.Net.Mail;
using
System.Net;
public
partial class _Default : System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e)
{
MailMessage m = newSystem.Net.Mail.MailMessage(―abc@gmail.com‖,―abc@gmail.com‖,―aaa‖,―asasasas‖);
try
{
NetworkCredential n = new NetworkCredential(―username‖, ―password‖);
SmtpClient s = new SmtpClient(―smtp.gmail.com‖, 587);
s.EnableSsl = true;
s.UseDefaultCredentials = false;
s.Credentials = n;
s.Send(m);
Response.Write(―m s‖);
}
catch (Exception)
{
throw;
}
}
}
Hyperlink in Asp.net
Default.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖Default.aspx.cs‖ Inherits=‖_Default‖ %>

<head runat=‖server‖>
  <title>Untitled Page</title>
</head>
<body>
  <form id=‖form1″ runat=‖server‖>
  <div>
  <asp:GridView ID=‖g1″ AutoGenerateColumns=‖false‖ runat=‖server‖>
  <Columns>
  <asp:HyperLinkField HeaderText=‖Emp Id‖ DataTextField=‖EmpId‖ DataNavigateUrlFields=‖EmpId‖
DataNavigateUrlFormatString=‖detail.aspx?temp={0}‖ />
  <asp:TemplateField HeaderText=‖Emp Name‖>
  <ItemTemplate>
  <asp:Label ID=‖lblEmpName‖ runat=‖server‖ Text=‘<%# bind(―EmpName‖) %>‘ ></asp:Label>
  </ItemTemplate>
  </asp:TemplateField>
  <asp:TemplateField HeaderText=‖Emp Salary‖>
  <ItemTemplate>
  <asp:Label ID=‖lblEmpSalary‖ runat=‖server‖ Text=‘<%# bind(―EmpSalary‖) %>‘ ></asp:Label>
  </ItemTemplate>
  </asp:TemplateField>

   </Columns>
   </asp:GridView>
   </div>
   </form>
</body>
</html>
Default.aspx.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.SqlClient;
public partial class _Default : System.Web.UI.Page
{
   SqlConnection con;
   SqlCommand cmd;
   SqlDataReader rd;
   public _Default()
   {
      con = new SqlConnection(―initial catalog=Employee;integrated security=yes‖);
      con.Open();
   }
   protected void Page_Load(object sender, EventArgs e)
   {
      if (!IsPostBack)
      {
          fillrecord();
      }
   }
   void fillrecord()
   {
      cmd = new SqlCommand(―select * from Emp‖,con);
      rd = cmd.ExecuteReader();
      g1.DataSource = rd;
      g1.DataBind();
   }
}
Detail.aspx
<%@ Page Language=‖C#‖ AutoEventWireup=‖true‖ CodeFile=‖detail.aspx.cs‖ Inherits=‖detail‖ %>
<head runat=‖server‖>
   <title>Untitled Page</title>
</head>
<body>
   <form id=‖form1″ runat=‖server‖>
   <div>
      <asp:GridView ID=‖GridView1″ runat=‖server‖>
      </asp:GridView>
   </div>
    </form>
</body>
</html>
detail.aspx.cs
using System;
using System.Collections;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Data.SqlClient;
public partial class detail : System.Web.UI.Page
{
    SqlConnection con;
    SqlCommand cmd;
    SqlDataReader rd;
    public detail()
    {
       con = new SqlConnection(―initial catalog=Employee;integrated security=yes‖);
       con.Open();
    }
    protected void Page_Load(object sender, EventArgs e)
    {
       if (!IsPostBack)
       {
           fillrecord();
       }
    }
    void fillrecord()
    {
       cmd = new SqlCommand(―select * from Empdetail where
empid=‖+Convert.ToInt32(Request.QueryString["temp"].ToString())+‖", con);
       rd = cmd.ExecuteReader();
       GridView1.DataSource = rd;
       GridView1.DataBind();
    }
}
Server-side options for storing page information typically have higher security than client-side options, but they can use
more Web server resources, which can lead to scalability issues when the size of the information store is large. ASP.NET
provides several options to implement server-side state management. For more information, see ASP.NET State
Management Overview.The following are the server-side state management options that ASP.NET supports:
ASP.NET offers you a variety of ways to maintain state information on the server, rather than persisting information on the
client. With server-based state management, you can decrease the amount of information sent to the client in order to
preserve state, however it can use costly resources on the server. The following sections describe three server-based state
management features: application state, session state, and profile properties.Application StateASP.NET allows you to
save values using application state — which is an instance of the HttpApplicationState class — for each active Web
application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus,
application state is useful for storing information that needs to be maintained between server round trips and between
requests for pages. For more information, see ASP.NET Application State Overview.Application state is stored in a
key/value dictionary that is created during each request to a specific URL. You can add your application-specific
information to this structure to store it between page requests.
Application state is stored in an instance of the HttpApplicationState class. This class exposes a key-value dictionary of
objects.TheHttpApplicationState instance is created the first time a user accesses any URL resource in an application.
The HttpApplicationState class is most often accessed through the Application property of the HttpContext class.You can
use application state in two ways. You can add, access, or remove values from the Contents collection directly through
code. The HttpApplicationStateclass can be accessed at any time during the life of an application. However, it is often
useful to load application state data when the application starts. To do so, you can put code to load application state into
the Application_Start method in the Global.asax file.Alternatively, you can add objects to the StaticObjects collection via an
<object runat=‖server‖> declaration in your Web application‘s Global.asax file. Application state defined in this way can
then be accessed from code anywhere in your application. The following example shows an object declaration for an
application state value:CopyYou can add objects to the StaticObjectscollection only in the Global.asax file. The collection
throws aNotSupportedException if you attempt to add objects directly through code.

				
DOCUMENT INFO
Shared By:
Tags: JAVA, .net, Spring
Stats:
views:24
posted:9/8/2012
language:
pages:53
Description: These documents are relater to .net,sql and specially for JAVA.