SchemaBinding option in views

Views can be thought of as a virtual table or stored query. The results of view are not stored in database (except for indexed views). The data accessed through a view is actually constructed using standard T-SQL select command and can come from one to many different base tables or even other views. This T-SQL select command is stored as a database object (a view). Developers can use the results from the view by referencing the view name in T-SQL statements the same way they would reference a real table. There are several advantages of using a view. They are: 1) A view can be used to limit the user to see only few columns in a table. A view can join several tables, in several databases on several servers, but all the user use is the view's name. 2) We can use views to manipulate the data. 3) Bcp utility and bulk insert works with a view. Basic syntax for a view goes like this: Create View <View Name> As <Select statement> GO Eg : Create View myView As Select EmpId , EmpName from Employees GO Here it will create a view named myView. Now instead of using the complete select statement to return the above result, you can just use a simple statement like this Select * from myView One of the important options that are used while creating a view is SCHEMABINDING. SCHEMABINDING Option Imagine that you have created a view with out SCHEMABINDING option and you have altered the schema of underlying table (deleted one column). Next time when you run your view, it will fail. Here is when SCHEMABINDING comes into picture. Creating a view with SCHEMABINDING option locks the underlying tables and prevents any changes that may change the table schema. Here is an example of a view with schemabinding option: Create View myView With schemabinding As Select EmpId , EmpName from dbo.Employees GO Remember that the object should be referred by their two-part name ( ownername.objectname) eg: dbo.Employees Now you wont be able to execute the alter statement on Employees table Cheers, God Bless