Differences between Sql server 2005, 2008, 2008r2, 2012

Difference between Sql server 2005 and 2008

Difference between Sql server 2008 and 2008r2

Difference between Sql server 2008 and 2012

Difference between Sql server 2005 and 2008

Sr No	SQL Server 2005	SQL Server 2008
1	XML datatype is introduced.	XML datatype is used.
2	Can not encrypt the entire database.	Can encrypt the entire database introduced in 2008.
3	Datetime is used for both date and time.	Date and time are seperately used for date and time
4	No table datatype is included.	Table datatype introduced.
5	SSIS is started using.	SSIS avails in this version.
6	CMS is not available.	Central Management Server(CMS) is Introduced.
7	PBM is not available	Policy based management(PBM) server is Introduced.

Difference between sqlserver 2008 and sqlserver 2012

Sql server 2012:
1.The SQL Server 2012 uses 48 bit precision for spatial
2.In SQL server 2012 has unlimited concurrent connections
3.By default it supports 15,000 partitions
4.Available new string functions CONCATE and FORMAT
5.Available new conversion  functions are PARSE ,TRY_CONVERT,TRY_PARSE
6.Microsoft.SqlServer.Dac and Microsoft.SqlServer.Dac.Extensions are introduced to perform  operations on Packages

Sql server 2008:
1.Maximum number concurrent connections to SQL Server 2008 is 32767
2.The SQL Server 2008 uses 27 bit precision for spatial
3.It can support only 1000 partitions
4.The CONCATE and FORMAT not available
5.Not available conversion function which are mentioned in SQL 2012

Difference between .NET 3.5 and .NET 4.0

	.NET 3.5	.NET 4.0
Definition	A version of .NET framework that preceded .NET 3.0	A version of .NET framework that preceded .NET 3.5
Direct Access to Client Data	No	Yes, using client data view and client data context objects
View State can be applied to the Control level	No	Yes, by using viewstate mechanism.
Permanent URL redirection	No	Yes, by using RedirectPermanent()
Size of installer	2.7 MB	869 KB
Enhanced features compared to previous versions	ASP.NET AJAX, Language Integrated Query (LINQ), enhanced Window Communication Foundation.	Improvements in CLR , BCL, data modeling, parallel programming, asp.net enhancements etc.
Output Caching	Yes, with limitation	Yes, easy to configure one or more custom output-cache providers.
Size of Web config file	Large due the Ajax, routing and integration with IIIS 7.	Can be empty or small as major configuration elements have been moved to the machine.config file.
Setting of Meta Tags	Two meta tags can be used- With name as keywords  With name as description	The keywords and meta tags can be included as part of page directive itself.
A control to  filter the data returns by EntitiyDataSource and LinqDataSource controls	Not present	Yes. QueryExtender Control
Hashing Algorithm	HMACSHA1	HMACSHA256

Asp.Net Page Life Cycle

INTRODUCTION :

Using Visual Studio, the development tool can develop very compelling applications using ASP.NET, with the ease of drag-and-drop server controls. Latest version finally announced by Microsoft. By adopting agile practices, and using IDE and ALM tools, Microsoft have been able to complete the release in half as many milestones this time around. Developing great apps for Windows 8 is an important goal of this release.

ASP.NET is the next generation web application framework developed and marketed by Microsoft based on .NET Framework. But not to be confused that it's not an upgraded version of ASP. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successful successor to Microsoft's Active Server Pages (ASP) technology.

ASP.NET allow programmers  to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.

HOW IT WORKS? :

Developing applications are easy unless you are familiar with the page life cycle process in order to correctly initialize controls. The life cycle of a control is based on the page life cycle, and the page raises many of the events that you need to handle in a custom control.

When a web browser requests a page from a web server, the web server will first check if the request is for an HTML page. If it is, the request is fulfilled by fetching the files from the OS and then returning it to the client (web browser). If the client is requesting an ASP.NET page, IIS will pass the request to the Asp.Net runtime, which will then process the application by reads the file, line by line, and executes the scripts in the file. After process complete it returns the output to the client as an format of pure html.

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend.

In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as

S = Start

I = Initialization

L = Load

V = Validate

E = Event Handlers

R = Render

Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:

PAGE REQUEST:

The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled, or whether a cached version of the page can be sent in response without running the page.

START:

In the start stage, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. The page also sets the UICulture property.

INITIALIZATION:

During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.

LOAD:

During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.

VALIDATE & EVENT HANDLING:

If the request is a postback, control event handlers are called. After that, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page. There is an exception to this sequence: the handler for the event that caused validation is called after validation.

RENDER:

Before rendering, view state is saved for the page and all controls. During the rendering stage, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream object of the page's Response property.

UNLOAD:

The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and cleanup is performed.

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code. Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true, page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init.

PreInit:

Raised after the start stage is complete and before the initialization stage begins. Use this event for the following: 

1. Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
2. Create or re-create dynamic controls.
3. Set a master page dynamically.
4. Set the Theme property dynamically.
5. Read or set profile property values.

If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

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_PreInit(object sender, EventArgs e)   

    {        

        /*  Use this event for the following:         

           Check the IsPostBack property to determine whether

            this is the first time the page  is being

            processed.       

        Create or re-create dynamic controls.

       Set a master page dynamically.        

     Set the Theme property dynamically.*/

  }

}

Init:

Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page. Use this event to read or initialize control properties.

protected void Page_Init(object sender, EventArgs e)

{

   /* Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties. */

}

InitComplete:

Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event. Use this event to make changes to view state that you want to make sure are persisted after the next postback.

protected void Page_InitComplete(object sender, EventArgs e)

{      

/* Raised by the  Page object. Use this event for processing tasks that require all initialization be complete. */

}

PreLoad:

Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.

protected override void OnPreLoad(EventArgs e)

{       

/* Use this event if you need to perform processing on your page or control before the  Load event.        // Before the Page instance raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.*/

}

Load:

The Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page. Use the OnLoad event method to set properties in controls and to establish database connections.

protected void Page_Load(object sender, EventArgs e)

{       

/* The  Page calls the  OnLoad event method on the  Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded. Use the OnLoad event method to set properties in controls and establish database connections.*/

}

Control Events:

Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event. In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.

protected void Button1_Click(object sender, EventArgs e)

{       

/* This is just an example of control event. Here it is button click event that caused the postback. */

}

Load Complete:

Raised at the end of the event-handling stage. Use this event for tasks that require that all other controls on the page be loaded.

protected void Page_LoadComplete(object sender, EventArgs e)

{       

/* Use this event for tasks that require that all other controls on the page be loaded.*/

}

PreRender:

Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page. Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.

protected override void OnPreRender(EventArgs e)

{       

/* Each data bound control whose DataSourceID property is set calls its DataBind method. The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.*/

}

PreRenderComplete:

Raised after each data bound control whose DataSourceID property is set calls its DataBind method.

SaveStateComplete:

Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.

protected override void OnSaveStateComplete(EventArgs e)

{       

/* Before this event occurs,  ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.        // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/

}

Render:

This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser. If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. A user control automatically incorporates rendering, so you do not need to explicitly render the control in code.

Unload:

Raised for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

protected void Page_UnLoad(object sender, EventArgs e)   

{       

/* This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream.    If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/

}

Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events. Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Load events for its child controls (top-down). Master pages behave like child controls on a page: the master page Init event occurs before the page Init and Load events, and the master page Load event occurs after the page Init and Load events.

If controls are created dynamically at run time or declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to the Controls collection.

DataBinding:

Raised after the control's PreRender event, which occurs after the page's PreRender event. This applies to controls whose DataSourceID property is set declaratively. Otherwise the event happens when you call the control's DataBind method. This event marks the beginning of the process that binds the control to the data. Use this event to manually open database connections, if required, and to set parameter values dynamically before a query is run.

RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :

Raised after the control's DataBinding event. Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.

RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :

Raised after the control's RowCreated or ItemCreated event. When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls in order to display related data within the row or item.

DataBound:

Raised at the end of data-binding operations in a data-bound control. In a GridView control, data binding is complete for all rows and any child controls. Use this event to format data-bound content or to initiate data binding in other controls that depend on values from the current control's content.

The Login control can use settings in the Web.config file to manage membership authentication automatically. However, if your application requires you to customize how the control works, or if you want to understand how Login control events relate to the page life cycle.

LoggingIn:

Raised during a postback, after the page's LoadComplete event has occurred. This event marks the beginning of the login process. Use this event for tasks that must occur prior to beginning the authentication process.

Authenticate:

Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.

LoggedIn:

Raised after the user name and password have been authenticated. Use this event to redirect to another page or to dynamically set the text in the control. This event does not occur if there is an error or if authentication fails.

LoginError:

Raised if authentication was not successful. Use this event to set text in the control that explains the problem or to direct the user to a different page.

Asp.Net Page Life Cycle

INTRODUCTION :

Using Visual Studio, the development tool can develop very compelling applications using ASP.NET, with the ease of drag-and-drop server controls. Latest version finally announced by Microsoft. By adopting agile practices, and using IDE and ALM tools, Microsoft have been able to complete the release in half as many milestones this time around. Developing great apps for Windows 8 is an important goal of this release.

ASP.NET is the next generation web application framework developed and marketed by Microsoft based on .NET Framework. But not to be confused that it's not an upgraded version of ASP. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successful successor to Microsoft's Active Server Pages (ASP) technology.

ASP.NET allow programmers  to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.

HOW IT WORKS? :

Developing applications are easy unless you are familiar with the page life cycle process in order to correctly initialize controls. The life cycle of a control is based on the page life cycle, and the page raises many of the events that you need to handle in a custom control.

When a web browser requests a page from a web server, the web server will first check if the request is for an HTML page. If it is, the request is fulfilled by fetching the files from the OS and then returning it to the client (web browser). If the client is requesting an ASP.NET page, IIS will pass the request to the Asp.Net runtime, which will then process the application by reads the file, line by line, and executes the scripts in the file. After process complete it returns the output to the client as an format of pure html.

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend.

In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as

S = Start

I = Initialization

L = Load

V = Validate

E = Event Handlers

R = Render

Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:

PAGE REQUEST:

The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled, or whether a cached version of the page can be sent in response without running the page.

START:

In the start stage, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. The page also sets the UICulture property.

INITIALIZATION:

During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.

LOAD:

During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.

VALIDATE & EVENT HANDLING:

If the request is a postback, control event handlers are called. After that, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page. There is an exception to this sequence: the handler for the event that caused validation is called after validation.

RENDER:

Before rendering, view state is saved for the page and all controls. During the rendering stage, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream object of the page's Response property.

UNLOAD:

The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and cleanup is performed.

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code. Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true, page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init.

PreInit:

Raised after the start stage is complete and before the initialization stage begins. Use this event for the following: 

1. Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
2. Create or re-create dynamic controls.
3. Set a master page dynamically.
4. Set the Theme property dynamically.
5. Read or set profile property values.

If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

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_PreInit(object sender, EventArgs e)   

    {        

        /*  Use this event for the following:         

           Check the IsPostBack property to determine whether

            this is the first time the page  is being

            processed.       

        Create or re-create dynamic controls.

       Set a master page dynamically.        

     Set the Theme property dynamically.*/

  }

}

Init:

Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page. Use this event to read or initialize control properties.

protected void Page_Init(object sender, EventArgs e)

{

   /* Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties. */

}

InitComplete:

Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event. Use this event to make changes to view state that you want to make sure are persisted after the next postback.

protected void Page_InitComplete(object sender, EventArgs e)

{      

/* Raised by the  Page object. Use this event for processing tasks that require all initialization be complete. */

}

PreLoad:

Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.

protected override void OnPreLoad(EventArgs e)

{       

/* Use this event if you need to perform processing on your page or control before the  Load event.        // Before the Page instance raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.*/

}

Load:

The Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page. Use the OnLoad event method to set properties in controls and to establish database connections.

protected void Page_Load(object sender, EventArgs e)

{       

/* The  Page calls the  OnLoad event method on the  Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded. Use the OnLoad event method to set properties in controls and establish database connections.*/

}

Control Events:

Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event. In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.

protected void Button1_Click(object sender, EventArgs e)

{       

/* This is just an example of control event. Here it is button click event that caused the postback. */

}

Load Complete:

Raised at the end of the event-handling stage. Use this event for tasks that require that all other controls on the page be loaded.

protected void Page_LoadComplete(object sender, EventArgs e)

{       

/* Use this event for tasks that require that all other controls on the page be loaded.*/

}

PreRender:

Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page. Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.

protected override void OnPreRender(EventArgs e)

{       

/* Each data bound control whose DataSourceID property is set calls its DataBind method. The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.*/

}

PreRenderComplete:

Raised after each data bound control whose DataSourceID property is set calls its DataBind method.

SaveStateComplete:

Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.

protected override void OnSaveStateComplete(EventArgs e)

{       

/* Before this event occurs,  ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.        // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/

}

Render:

This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser. If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. A user control automatically incorporates rendering, so you do not need to explicitly render the control in code.

Unload:

Raised for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

protected void Page_UnLoad(object sender, EventArgs e)   

{       

/* This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream.    If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/

}

Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events. Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Load events for its child controls (top-down). Master pages behave like child controls on a page: the master page Init event occurs before the page Init and Load events, and the master page Load event occurs after the page Init and Load events.

If controls are created dynamically at run time or declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to the Controls collection.

DataBinding:

Raised after the control's PreRender event, which occurs after the page's PreRender event. This applies to controls whose DataSourceID property is set declaratively. Otherwise the event happens when you call the control's DataBind method. This event marks the beginning of the process that binds the control to the data. Use this event to manually open database connections, if required, and to set parameter values dynamically before a query is run.

RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :

Raised after the control's DataBinding event. Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.

RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :

Raised after the control's RowCreated or ItemCreated event. When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls in order to display related data within the row or item.

DataBound:

Raised at the end of data-binding operations in a data-bound control. In a GridView control, data binding is complete for all rows and any child controls. Use this event to format data-bound content or to initiate data binding in other controls that depend on values from the current control's content.

The Login control can use settings in the Web.config file to manage membership authentication automatically. However, if your application requires you to customize how the control works, or if you want to understand how Login control events relate to the page life cycle.

LoggingIn:

Raised during a postback, after the page's LoadComplete event has occurred. This event marks the beginning of the login process. Use this event for tasks that must occur prior to beginning the authentication process.

Authenticate:

Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.

LoggedIn:

Raised after the user name and password have been authenticated. Use this event to redirect to another page or to dynamically set the text in the control. This event does not occur if there is an error or if authentication fails.

LoginError:

Raised if authentication was not successful. Use this event to set text in the control that explains the problem or to direct the user to a different page.

Asp.Net Page Life Cycle

INTRODUCTION :

Using Visual Studio, the development tool can develop very compelling applications using ASP.NET, with the ease of drag-and-drop server controls. Latest version finally announced by Microsoft. By adopting agile practices, and using IDE and ALM tools, Microsoft have been able to complete the release in half as many milestones this time around. Developing great apps for Windows 8 is an important goal of this release.

ASP.NET is the next generation web application framework developed and marketed by Microsoft based on .NET Framework. But not to be confused that it's not an upgraded version of ASP. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successful successor to Microsoft's Active Server Pages (ASP) technology.

ASP.NET allow programmers  to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.

HOW IT WORKS? :

Developing applications are easy unless you are familiar with the page life cycle process in order to correctly initialize controls. The life cycle of a control is based on the page life cycle, and the page raises many of the events that you need to handle in a custom control.

When a web browser requests a page from a web server, the web server will first check if the request is for an HTML page. If it is, the request is fulfilled by fetching the files from the OS and then returning it to the client (web browser). If the client is requesting an ASP.NET page, IIS will pass the request to the Asp.Net runtime, which will then process the application by reads the file, line by line, and executes the scripts in the file. After process complete it returns the output to the client as an format of pure html.

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend.

In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as

S = Start

I = Initialization

L = Load

V = Validate

E = Event Handlers

R = Render

Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:

PAGE REQUEST:

The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled, or whether a cached version of the page can be sent in response without running the page.

START:

In the start stage, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. The page also sets the UICulture property.

INITIALIZATION:

During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.

LOAD:

During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.

VALIDATE & EVENT HANDLING:

If the request is a postback, control event handlers are called. After that, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page. There is an exception to this sequence: the handler for the event that caused validation is called after validation.

RENDER:

Before rendering, view state is saved for the page and all controls. During the rendering stage, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream object of the page's Response property.

UNLOAD:

The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and cleanup is performed.

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code. Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the @ Page directive is set to true, page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init.

PreInit:

Raised after the start stage is complete and before the initialization stage begins. Use this event for the following: 

1. Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
2. Create or re-create dynamic controls.
3. Set a master page dynamically.
4. Set the Theme property dynamically.
5. Read or set profile property values.

If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

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_PreInit(object sender, EventArgs e)   

    {        

        /*  Use this event for the following:         

           Check the IsPostBack property to determine whether

            this is the first time the page  is being

            processed.       

        Create or re-create dynamic controls.

       Set a master page dynamically.        

     Set the Theme property dynamically.*/

  }

}

Init:

Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page. Use this event to read or initialize control properties.

protected void Page_Init(object sender, EventArgs e)

{

   /* Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties. */

}

InitComplete:

Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event. Use this event to make changes to view state that you want to make sure are persisted after the next postback.

protected void Page_InitComplete(object sender, EventArgs e)

{      

/* Raised by the  Page object. Use this event for processing tasks that require all initialization be complete. */

}

PreLoad:

Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.

protected override void OnPreLoad(EventArgs e)

{       

/* Use this event if you need to perform processing on your page or control before the  Load event.        // Before the Page instance raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.*/

}

Load:

The Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page. Use the OnLoad event method to set properties in controls and to establish database connections.

protected void Page_Load(object sender, EventArgs e)

{       

/* The  Page calls the  OnLoad event method on the  Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded. Use the OnLoad event method to set properties in controls and establish database connections.*/

}

Control Events:

Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event. In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.

protected void Button1_Click(object sender, EventArgs e)

{       

/* This is just an example of control event. Here it is button click event that caused the postback. */

}

Load Complete:

Raised at the end of the event-handling stage. Use this event for tasks that require that all other controls on the page be loaded.

protected void Page_LoadComplete(object sender, EventArgs e)

{       

/* Use this event for tasks that require that all other controls on the page be loaded.*/

}

PreRender:

Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page. Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.

protected override void OnPreRender(EventArgs e)

{       

/* Each data bound control whose DataSourceID property is set calls its DataBind method. The PreRender event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.*/

}

PreRenderComplete:

Raised after each data bound control whose DataSourceID property is set calls its DataBind method.

SaveStateComplete:

Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.

protected override void OnSaveStateComplete(EventArgs e)

{       

/* Before this event occurs,  ViewState has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.        // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/

}

Render:

This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser. If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. A user control automatically incorporates rendering, so you do not need to explicitly render the control in code.

Unload:

Raised for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

protected void Page_UnLoad(object sender, EventArgs e)   

{       

/* This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections. During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream.    If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/

}

Individual ASP.NET server controls have their own life cycle that is similar to the page life cycle. For example, a control's Init and Load events occur during the corresponding page events. Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event (and also the Unload event) for each child control occur before the corresponding event is raised for its container (bottom-up). However the Load event for a container occurs before the Load events for its child controls (top-down). Master pages behave like child controls on a page: the master page Init event occurs before the page Init and Load events, and the master page Load event occurs after the page Init and Load events.

If controls are created dynamically at run time or declaratively within templates of data-bound controls, their events are initially not synchronized with those of other controls on the page. For example, for a control that is added at run time, the Init and Load events might occur much later in the page life cycle than the same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically added controls and controls in templates raise their events one after the other until they have caught up to the event during which it was added to the Controls collection.

DataBinding:

Raised after the control's PreRender event, which occurs after the page's PreRender event. This applies to controls whose DataSourceID property is set declaratively. Otherwise the event happens when you call the control's DataBind method. This event marks the beginning of the process that binds the control to the data. Use this event to manually open database connections, if required, and to set parameter values dynamically before a query is run.

RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :

Raised after the control's DataBinding event. Use this event to manipulate content that is not dependent on data binding. For example, at run time, you might programmatically add formatting to a header or footer row in a GridView control.

RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :

Raised after the control's RowCreated or ItemCreated event. When this event occurs, data is available in the row or item, so you can format data or set the FilterExpression property on child data source controls in order to display related data within the row or item.

DataBound:

Raised at the end of data-binding operations in a data-bound control. In a GridView control, data binding is complete for all rows and any child controls. Use this event to format data-bound content or to initiate data binding in other controls that depend on values from the current control's content.

The Login control can use settings in the Web.config file to manage membership authentication automatically. However, if your application requires you to customize how the control works, or if you want to understand how Login control events relate to the page life cycle.

LoggingIn:

Raised during a postback, after the page's LoadComplete event has occurred. This event marks the beginning of the login process. Use this event for tasks that must occur prior to beginning the authentication process.

Authenticate:

Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.

LoggedIn:

Raised after the user name and password have been authenticated. Use this event to redirect to another page or to dynamically set the text in the control. This event does not occur if there is an error or if authentication fails.

LoginError:

Raised if authentication was not successful. Use this event to set text in the control that explains the problem or to direct the user to a different page.