ACID (Atomicity, Consistency, Integrity, Durability) in SQL Server

ACID (an acronym for Atomicity Consistency Isolation Durability) is a concept that every database management system must strive to achieve. For a reliable database all these four attributes should be achieved.

Atomicity: stats 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.

Consistency: stats that a transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its previous state. It means a transaction will never leave your database in a half finished state.

Integrity: keeps transaction separated each other until they are finished. A transaction in process and yet not committed must remain isolated from any other transaction.

Durability: ensures that any transaction committed to the database will not be lost. Committed data are saved by the system in such a way that, even in the event of failure or system restart, the data is available in its correct state.

Table Variables in Sql Server 2005


Table variable is almost similar to the temporary table in sql server 2005. Table variables are replacement to temporary tables. The following syntax shows how to define a table variable.

Declare @Customer table ( CustomerID int identity(1,1), CustomerName varchar(100), CompanyName varchar(100), Address varchar(250) )

You can notice the syntax to define a table variable is similar to the syntax to normal table definition. declare keyword is used in place of create keyword. And table name is prefixed with ‘@’ as all tsql variables do.


1.Table variables are stored in memory rather than in database.


2.Querying table variables is very fast as there are no disk reads needed.


3.The scope the table variables is same as other tsql variables. i.e, within statements batch or sproc


4.Table variables cannot be dropped as they are automatically disappeared when they reach out scope


5.As explained above all the data in table variables is stored in server’s memory. So if there is huge data then it is not recommended to use table variables to avoid memory overhead.


6.If the number of records is more than 100 then it is recommended to use temporary tables.To learn more about temporary tables please read this blog post :



How to create temporary table in sql server 2005?

The syntax to create a temporary table is exactly same as the syntax to create a normal table. But the difference is the table name is prefixed with ‘#’ (pound). By looking at the prefix ‘#’ the sql server understands that it is a temporary table. The following code demonstrates how to create a temporary variable.

CREATE TABLE #Customer ( CustomerID int identity(1,1), CustomerName varchar(100), CompanyName varchar(100), Address varchar(250) )

1.It is almost similar to normal table with very few exceptions.


2.The scope of the temp table is the current connection session. It can be accessed from any where in same connection session.


3.This table is automatically dropped when the connection session is closed.


4.Different connection sessions creating temporary table with same name will create different copies of the temporary table with the same name. Actually internally the table name is appended with a unique number to support many connection sessions creating tables with same name. You can notice how the table name is uniquely maintained by sql server by running this query. select * from information_schema.tables where table_name like ‘%customer%’


5.foreign key relations cannot be applied to temp tables.


6.Optionally you may drop the table at the end of it’s use. It is a good practice to drop any temporary table after use. drop table #Customer


When you create a temporary table it will be created in tempdb. At the time of table creation the tempdb is locked and hence there is some overhead involved using this. If there are less than 100 records then using temporary tables is not recommended. In such cases you can use table variables which are stored in memory rather than in database(on disk). To learn more about table variables please read this :


Saving changes after table edit in SQL Server Management Studio 2008

Question : If we want to save any changes in a table, previously saved in SQL Server Management Studio (no data in table present) we get an error message :


Saving changes is not permitted. The changes you have made require the following tables to be dropped and re-created. You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created.


What can prevent the table to be easily edited? Or, is it the usual way for SQL Server Management Studio to require re-creating table for editing? What is it – this “option Prevent saving changes”?


Answer : This problem occurs when “Prevent saving changes that require table re-creation” option is enabled.

Go into Tools -> Options -> Designers-> Uncheck “Prevent saving changes that require table re-creation”.

That happens because sometimes it is necessary to drop and recreate a table in order to change something. This can take a while, since all data must be copied to a temp table and then re-inserted in the new table. Since SQL Server by default doesn’t trust you, you need to say “OK, I know what I’m doing, now let me do my work.”