ACID RULES OF TRANSACTION

What are ACID Rules of transaction in a database? 
Atomicity, Consistency, Isolation, Durability


Atomicity - This rule states that either the complete transaction takes place, or none. Even if a part of a transaction fails to work, the complete transaction will fail.
Atomicity states that database modifications must follow an “all or nothing” rule. Each transaction is said to be “atomic.” If one part of the transaction fails, the entire transaction fails. It is critical that the database management system maintain the atomic nature of transactions in spite of any DBMS, operating system or hardware failure.

Consistency - This rule ensures that the database is stable,before and after the transaction, even if a transaction fails
Consistency states that only valid data will be written to the database. If, for some reason, a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules. On the other hand, if a transaction successfully executes, it will take the database from one state that is consistent with the rules to another state that is also consistent with the rules.

Isolation - Keeps transactions separated from each other until they’re finished.

Isolation requires that multiple transactions occurring at the same time not impact each other’s execution. For example, if Joe issues a transaction against a database at the same time that Mary issues a different transaction, both transactions should operate on the database in an isolated manner. The database should either perform Joe’s entire transaction before executing Mary’s or vice-versa. This prevents Joe’s transaction from reading intermediate data produced as a side effect of part of Mary’s transaction that will not eventually be committed to the database. Note that the isolation property does not ensure which transaction will execute first, merely that they will not interfere with each other.

Durability - Guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination.

Durability ensures that any transaction committed to the database will not be lost. Durability is ensured through the use of database backups and transaction logs that facilitate the restoration of committed transactions in spite of any subsequent software or hardware failures.

SQL SERVER Differences 2000,2005 and 2008

SQL SERVER Differences 2000,2005 and 2008

SQL SERVER 2000	SQL SERVER 2005	SQL SERVER 2008
1.Query Analyser and Enterprise manager are separate.	1.Both are combined as SSMS(Sql Server management Studio).	1.Both are combined as SSMS(Sql Server management Studio).
2.No XML datatype is used.	2.XML datatype is introduced.	2.XML datatype is used.
3.We can create maximum of 65,535 databases.	3.We can create 2(pow(20))-1 databases.	3.We can create 2(pow(20))-1 databases.
4.Nill	4.Exception Handling	4.Exception Handling
5.Nill	5.Varchar(Max) data type	5.Varchar(Max) data type
6.Nill	6.DDL Triggers	6.DDL Triggers
7.Nill	7.DataBase Mirroring	7.DataBase Mirroring
8.Nill	8.RowNumber function for paging	8.RowNumber function for paging
9.Nill	9.Table fragmentation	9.Table fragmentation
10.Nill	10.Full Text Search	10.Full Text Search
11.Nill	11.Bulk Copy Update	11.Bulk Copy Update
12.Nill	12.Cant encrypt	12.Can encrypt the entire database introduced in 2008. --check it(http://technet.microsoft.com/en-us/library/cc278098(SQL.100).aspx) (http://www.sqlservercentral.com/articles/Administration/implementing_efs/870/) (http://www.kodyaz.com/articles/sql-server-2005-database-encryption-step-by-step.aspx) (http://www.sql-server-performance.com/articles/dev/encryption_2005_1_p1.aspx) (http://geekswithblogs.net/chrisfalter/archive/2008/05/08/encrypt-documents-with-sql-server.aspx)
13.cant compress the tables and indexes.	13.Can Compress tables and indexes.(Introduced in 2005 SP2)	13.Can compress tables and indexes. -http://www.mssqltips.com/tip.asp?tip=1582
14.Datetime datatype is used for both date and time.	14.Datetime is used for both date and time.	14.Date and time are seperately used for date and time datatype,geospatial and timestamp with internal timezone is used.
15.No varchar(max) or varbinary(max) is available.	15.Varchar(max) and varbinary(max) is used.	15.Varchar(max) and varbinary(max) is used.
16.No table datatype is included.	16.No table datatype is included.	16.Table datatype introduced.
17.No SSIS is included.	17.SSIS is started using.	17.SSIS avails in this version
18.CMS is not available.	18.CMS is not available.	18.Central Management Server(CMS) is Introduced. -http://msdn.microsoft.com/en-us/library/bb934126.aspx -http://www.sqlskills.com/BLOGS/KIMBERLY/post/SQL-Server-2008-Central-Management-Servers-have-you-seen-these.aspx
19.PBM is not available.	19.PBM is not available.	19.Policy based management(PBM) server is Introduced. -http://www.mssqltips.com/tip.asp?tip=1492 -http://msdn.microsoft.com/en-us/library/bb510667.aspx

ASP .NET Page Life Cycle

PreInit 

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.
• Read or set profile property values.
Note: 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.

Init 

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 by the Page object. Use this event for processing tasks that require all initialization
be complete.

PreLoad 

 Use this event if you need to perform processing on your page or control before the Load
event. After the Page 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 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.

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.

LoadComplete

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

PreRender

Before this event occurs:
• The Page object calls EnsureChildControls for each control and for the page.
• 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.

SaveStateComplete

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 that is sent 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 (an .ascx file) automatically
incorporates rendering, so you do not need to explicitly render the control in code.

Unload

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. 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. Note: 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.