Web form pages are HTTP-Based, they are stateless, which means they don’t know whether the requests are all from the same client, and pages are destroyed and recreated with each round trip to the server, therefore information will be lost, therefore state management is really an issue in developing web applications

We could easily solve these problems in ASP with cookie, query string, application, session and so on. Now in ASP.NET, we still can use these functions, but they are richer and more powerful, so let’s dive into it.

Mainly there are two different ways to manage web page’s state: Client-side and Server-side.

Client-side state management :

Cookies

View state

Hidden fields

Query string

Server-side state management

Application state object

Session state object

Database support

Profile Properties

the differences between cookies, view state ,session state ,application state.

Mainly there are two different ways to manage web page’s state: Client-side and Server-side.

1.Client-side state management :

Cookies
You need to store small amounts of information on the client and security is not an issue.

View state
You need to store small amounts of information for a page that will post back to itself. Use of the ViewState property does supply semi-secure functionality.

Hidden fields
You need to store small amounts of information for a page that will post back to itself or another page, and security is not an issue. Note You can use a hidden field only on pages that are submitted to the server.

Query string
You are transferring small amounts of information from one page to another and security is not an issue. Note You can use query strings only if you are requesting the same page, or another page via a link.

2.Server-side state management

Application state object
You are storing infrequently changed, application-scope information that is used by many users, and security is not an issue. Do not store large quantities of information in an application state object.

Session state object
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 a session state object. 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.

Database support
You are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.
global.asax file.

Allows to handle application or session events. (Application_Start,Application_End,Session_Start,Session_End)

check this link about global.asax

http://as palliance.com/articleViewer.aspx?aId=440&pId=

app_code,app_theme,page_init

ASP.NET 2.0 introduces the App_Code directory, which can contain standalone files that contain code to be shared across several pages in your application. Unlike ASP.NET 1.x, which required these files to be precompiled to the Bin directory, any code files in the App_Code directory will be dynamically compiled at runtime and made available to the application.

Cookies: Are small text files stored in the client machine (approximately 4 kb max size) in which you can save personal data or other data about the user.

viewstate: If it is enabled on a webform, a hidden field will be added to the form to enable the controls to maintain state across postbacks

Session state: For each user connected to your application, ASP.NET will create a session, Session states by default are being stored on the webserver's memory. Session variables are unique per user and maintain their values across the duration of the session.

Application state: is shared by all users. Once you save a value inside an application state, all users can access it. Application variables maintain their values across application duration.

Create FUNCTION [dbo].[iter$simple_intlist_to_tbl] (@list varchar(MAX))

RETURNS @tbl TABLE (number varchar(50) NOT NULL) AS

BEGIN

DECLARE @pos int,

@nextpos int,

@valuelen int

SELECT @pos = 0, @nextpos = 1

WHILE @nextpos > 0

BEGIN

SELECT @nextpos = charindex(',', @list, @pos + 1)

SELECT @valuelen = CASE WHEN @nextpos > 0

THEN @nextpos

ELSE len(@list) + 1

END - @pos - 1

INSERT @tbl (number)

VALUES (convert(varchar(50), substring(@list, @pos + 1, @valuelen)))

SELECT @pos = @nextpos

END

RETURN

END

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

GO

ALTER procedure [dbo].[usp_Insert_InterimSemester_Classes_Courses]

(

@AcademicId uniqueidentifier

,@CreatedBy uniqueidentifier

,@CreatedOn datetime

,@UpdatedBy uniqueidentifier

,@UpdatedOn datetime

,@InterimTourId varchar(MAX)

)

AS

BEGIN

insert into D_Interim_Semester_Classes

(

AcademicId

,CreatedBy

,CreatedOn

,UpdatedBy

,UpdatedOn

)

values

(

@AcademicId

,@CreatedBy

,@CreatedOn

,@UpdatedBy

,@UpdatedOn

)

declare @ClassId int

set @ClassId=@@identity

select * into #temp1 from iter$simple_intlist_to_tbl(@InterimTourId) i

declare GetInsetItems cursor global

scroll

dynamic

optimistic

for select * from #temp1

open GetInsetItems

declare @InterTourID varchar(50)

Fetch First from GetInsetItems into @InterTourID

while @@fetch_status=0

begin

insert into D_Interim_Semester_Classes_Courses (ClassId ,InterimTourId)

values(@ClassId,@InterTourID)

fetch next from GetInsetItems into @InterTourID

print @InterTourID

end

close GetInsetItems

deallocate GetInsetItems

end