CREATE TABLE dbo.Contact
(
	Id INTEGER IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
	FirstName VARCHAR(50) NOT NULL,
	LastName VARCHAR(50) NOT NULL,
	DOB DATETIME NOT NULL,
	Phone VARCHAR(30) NULL,
	Email VARCHAR(200) NULL,
	Mobile VARCHAR(20) NULL,
	Website VARCHAR(100) NULL
);

Insert a test record.

INSERT INTO dbo.Contacts
(
	FirstName,
	LastName,
	DOB,
	Email,
	Website
)
VALUES
(
	'Rhys',
	'Campbell',
	'01-Jun-80',
	'noone@tempinbox.com',
	'http://www.youdidwhatwithtsql.com'
);

Create a view on this table.

CREATE VIEW vw_Contacts
AS
	SELECT *
	FROM dbo.Contacts;

Verify the view is functional

SELECT *
FROM vw_Contacts;

Now drop a column from the Contacts table.

ALTER TABLE dbo.Contacts DROP COLUMN Phone;

Now try selecting from the view again.

SELECT *
FROM vw_Contacts;

So what’s going on here? The view is expecting the Phone column to still be in the Contact table. We created our view with an asterisk so this shouldn’t matter right? Uvavu! SQL Server stores metadata about the view when you create it. Changes to underlying tables can cause issues. Luckily the fix is easy.

EXEC sp_refreshview 'vw_Contacts';

SELECT *
FROM vw_Contacts;

This procedure will update the metadata stored by the view making it functional again. Presumably this is akin to dropping and recreating the view. This is a fairly trivial example but in a large system, with lots of views, and lots of developers, this could cause big headaches. I recommend you read the MSDN page for sp_refreshview. There’s a couple of useful scripts in the comments section for making light work of this.

Post from: youdidwhatwithtsql.com

View or function ‘dbo.Viewname’ has more column names specified than columns defined

Msg 4429, Level 16, State 1, Line 1
View or function ‘Table_1′ contains a self-reference. Views or functions cannot reference themselves directly or indirectly.
Msg 4413, Level 16, State 1, Line 1
Could not use view or function ‘Test.Table_1′ because of binding errors.

Here’s a quick walk-through of the issue.

CREATE TABLE [dbo].[Table_1]
(
	[id] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
	[test] [nchar](10) NOT NULL
);

Insert some test data

INSERT INTO dbo.Table_1
(
	test
)
SELECT 'One'
UNION ALL
SELECT 'Two'
UNION ALL
SELECT 'Three'
UNION ALL
SELECT 'Four'
UNION ALL
SELECT 'Five';

Add a schema called ‘Test’ to the database by running the TSQL below. We will then create a view in this schema.

CREATE SCHEMA Test;

Now create this view.

CREATE VIEW Test.Table_1
AS
	SELECT Id, Test
	FROM Table_1;

Now try to select from this view.

I’d been creating lots of views for a third party application we’ve started to deploy at work. I’d simply created a new schema and named the views after the corresponding table in the database. This one was my fault for being a copy and paste monkey! I’d forgotten to specify the schema in one view. The fix?

ALTER VIEW Test.Table_1
AS
	SELECT Id, Test
	FROM dbo.Table_1;

Even though my user default schema was set to dbo SQL Server got its pants in a twist over this. So there you have it; it’s definitely good practice to specify schemas in your TSQL!

Post from: youdidwhatwithtsql.com

Views or functions cannot reference themselves directly or indirectly