Site sponsored by: Idera Try Idera’s new SQL admin toolset
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Quiz
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


Article Topics

All Articles
Performance Tuning
Audit
Business Intelligence
Clustering
Reporting Services
Developer
General DBA
ASP.NET / ADO.NET

Write for Us

Share you SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

Filtered Indexes in SQL Server 2008
Importance of Database Backups and Recovery Plan
Data Compression in SQL Server 2008
SQL Server 2008 MERGE Statement

More     
 
Latest FAQ's

ALTER TABLE SWITCH statement failed because the object '%.*ls' is not ...
ALTER TABLE SWITCH statement failed because column '%.*ls' at ordinal %d ...
ALTER TABLE SWITCH statement failed because table '%.*ls' has %d columns ...
SQL Server Reporting Server (SSRS) service is failing to start ...

More     
   
Latest Software Reviews

Spotlight on ApexSQL Doc 2008
ApexSQL Enforce
Embarcadero Change Manager
SQL Server DBA Dashboard

More     

articles >> developer >> Views in SQL Server

Views in SQL Server

By : Steve Manik
May 17, 2004

Page 3 / 3



Dropping Views

You can drop a view from a database by using the DROP VIEW statement. When a view is dropped, it has no effect on the underlying tables. Dropping a view removes its definition and all the permissions assigned to it. Furthermore, if you query any views that reference a dropped view, you receive an error message. However, dropping a table that references a view does not drop the view automatically. You must drop it explicitly.

Syntax

DROP VIEW view_name

Where:

view_name is the name of the view to be dropped.

You can drop multiple views with a single DROP VIEW statement. The names of the views that need to be dropped are separated by commas in the DROP VIEW statement.

Note

If a view is defined with the select *statement and the base table is altered by adding a few columns, the new columns do not get included in the view. The asterisk(*) symbol is interpreted and expanded only when the view is created. In order to access the new columns via the view, it is necessary to drop the view and recreate it.

If the underlying object is dropped, the views based on the object becomes inactive and any attempt to query data from the view will result in an error message.



Renaming Views

You can rename a view without having to drop it. This ensures that the permissions on the view are not lost.

The guidelines for renaming a view are as follows:

  • The view must be in the current database.
  • The new name for the view must be followed by the rules for identifiers.
  • A view can be renamed only by its owner.
  • A view can also be renamed by the owner of the database.
  • A view can be renamed by using the sp_rename system stored procedure.

Syntax

Sp_rename_old_viewname, new_viewname

Where:

old_viewname is the view that needs to be renamed.

new_viewname is the new name of the view.

Example

Sp_rename vwCutomers vwCustomerDetails

Renames vwCutomers to vwCustomerDetails.



Manipulating Data Using Views

You can modify data by using a view in only one of its base tables even though a view may be derived from multiple underlying tables. For example, a view vwNew that is derived from two tables, table and table2, can be used to modify either table or table2 in a single statement. A single data modification statement that affected both the underlying tables is not permitted.

You cannot modify the following of Columns using a view:

  • Columns that are based on computed values.
  • Columns that are based on built_in_function like numeric and string functions.
  • Columns that are based on row aggregate functions.

Consider a situation in which a table contains a few Columns that have been defined as NOT NULL, but the view derived from the table does not contain any of these NOT NULL columns. During an INSERT operation, there may be situation where:

All the NOT NULL columns in the base tables are defined with default values.

In the first case, the INSERT operation will be successful because the default values are supplied for the NOT NULL columns. In the second case, the INSERT operation will fail because default values are not supplied for the NOT NULL columns.


<< Prev Page         








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 1999-2008 by T10 Media. All rights reserved