FROM http://sqlstudies.com/2013/01/20/my-view-isnt-reflecting-changes-ive-made-to-the-underlying-tables/
Problem: You’ve added columns to the base table of one of your views, but the view isn’t reflecting the change.
Over the years I’ve seen lot’s of views created similar to this one.
|
1
2
|
CREATE
VIEW
vw_TableView AS
SELECT
* FROM
TableName
|
Generally the argument is that if I put “SELECT *” rather than an explicit field list, then when my table changes so will my view. Unfortunately it doesn’t work that way.
Let’s try an example.
Create a test table and populate it with some data.
|
1
2
3
4
5
6
7
8
9
10
|
CREATE
TABLE
TableName (Column1 varchar(10))
GOINSERT
INTO
TableName VALUES
(‘abcdefg‘)
INSERT
INTO
TableName VALUES
(‘hij‘)
INSERT
INTO
TableName VALUES
(‘klmnop‘)
INSERT
INTO
TableName VALUES
(‘qrstuvwxy‘)
INSERT
INTO
TableName VALUES
(‘zabcde‘)
INSERT
INTO
TableName VALUES
(‘123456‘)
GO |
Create a test view.
|
1
2
3
|
CREATE
VIEW
vw_TableView AS
SELECT
* FROM
TableName
GO |
Test the view to make sure we are getting the data we expect.
|
1
2
|
SELECT
* FROM
vw_TableView
GO |
So far so good. The output is exactly what we expected. Now let’s add a column to the table and populate it.
|
1
2
3
4
|
ALTER
TABLE
TableName ADD
Column2 INT
GOUPDATE
TableName SET
Column2 = 3
GO |
And try out the view again.
|
1
2
|
SELECT
* FROM
vw_TableView
GO |
| Column1 |
| abcdefg |
| hij |
| klmnop |
| qrstuvwxy |
| zabcde |
| 123456 |
Now wait just a minute. The output I’m getting looks exactly like it did before I added Column2. All I’m seeing is Column1. Now the first thing I do when debugging something like this is make sure the view should in fact be pulling the new column. So:
|
1
|
EXEC
sp_helptext vw_TableView
|
|
1
2
3
4
5
|
Text---------------------------------------------------------------CREATE VIEW vw_TableView AS SELECT * FROM TableName
|
Ok, so the code still looks correct. So why aren’t we pulling all of the columns even though we are using a *? From what I understand the metadata for the view is not automatically updated when the tables are modified.
The fix is to either drop and re-create or alter the view or to use the sp_refreshview stored procedure. Sp_refreshview has the combined benefit of being the simplest method and not messing up any explicit permissions on the view caused by dropping it.
|
1
2
|
EXEC
sp_RefreshView vw_TableView
GO |
And test the view again.
|
1
2
|
SELECT
* FROM
vw_TableView
GO |
| Column1 | Column2 |
| abcdefg | 3 |
| hij | 3 |
| klmnop | 3 |
| qrstuvwxy | 3 |
| zabcde | 3 |
| 123456 | 3 |
And now we have the correct number of columns for our view.
Next let’s try
going the other way. We remove a column from the table.
|
1
2
|
ALTER
TABLE
TableName DROP
Column2
GO |
And we try querying the view again. (I’m hoping no one expects it to work correctly.)
|
1
2
|
SELECT
* FROM
vw_TableView
GO |
This time we get an error.
|
1
2
|
Msg 4502, Level 16, State 1, Line 1View or function ‘vw_TableView‘ has more column names specified than columns defined. |
If we again run sp_refreshview then the view will once again show the expected data.
|
1
2
3
4
|
EXEC
sp_RefreshView vw_TableView
GOSELECT
* FROM
vw_TableView
GO |
| Column1 |
| abcdefg |
| hij |
| klmnop |
| qrstuvwxy |
| zabcde |
| 123456 |
And last but not least some cleanup code.
|
1
2
3
|
DROP
VIEW
vw_TableView
DROP
TABLE
TableName
GO |
my-view-isnt-reflecting-changes-ive-made-to-the-underlying-tables