|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 5:57 AM
Points: 5,122,
Visits: 20,366
|
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 10:46 PM
Points: 1,114,
Visits: 983
|
|
Hi Bit bucket,
Thanks for the question. I would expect to attach any external reference to the question. Thought it is easier question for experienced person, it will help for the beginners.
Thank you.
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Today @ 2:23 AM
Points: 505,
Visits: 971
|
|
Thanks! Easy one for a Tuesday....
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 1,996,
Visits: 1,864
|
|
Easy question! Good practice is never use "SELECT * FROM" in view, too.
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Yesterday @ 5:34 AM
Points: 867,
Visits: 338
|
|
I'm a bit confused. BOL: If a view is not created with the SCHEMABINDING clause, sp_refreshview should be run when changes are made to the objects underlying the view that affect the definition of the view. Otherwise, the view might produce unexpected results when it is queried.
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 8:11 AM
Points: 5,296,
Visits: 7,237
|
|
palotaiarpad (3/27/2012) I'm a bit confused. BOL: If a view is not created with the SCHEMABINDING clause, sp_refreshview should be run when changes are made to the objects underlying the view that affect the definition of the view. Otherwise, the view might produce unexpected results when it is queried. What exactly are you confused about? This question is not at odds with the "unexpected results" quote in Books Online, as this error is just one of the possible unexpected results you can get; you only get this when the number of columns has been reduced. Other weird stuff is possible as well - see for instance this demo, that removes the "first" column of the table, then adds a new one.
CREATE TABLE t1 (IntCol int, CharCol varchar(20), DateCol date); GO INSERT INTO t1(IntCol, CharCol, DateCol) VALUES (1, 'One', '2012-01-01'), (2, 'Two', '2012-02-02'); GO CREATE VIEW v1 AS SELECT * FROM t1; GO SELECT * FROM v1; GO ALTER TABLE t1 DROP COLUMN IntCol; ALTER TABLE t1 ADD NewIntCol int; GO UPDATE t1 SET NewIntCol = 0; GO SELECT * FROM v1; GO DROP VIEW v1; DROP TABLE t1; GO Finally, note that just adding columns does not affect the results from the view; if you comment out the alter table drop column in the code above, the view will keep returning correct results. But dropping the table and recreating it with the columns in a different order (or reordering the columns through the SSMS table designer - which does the exact same thing under the covers) will have similar effects as the code above.
Hugo Kornelis, SQL Server MVP Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 1:58 AM
Points: 2,499,
Visits: 2,199
|
|
Thanks Ron - good question.
------------------------------- Posting Data Etiquette - Jeff Moden Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan I would never join a club that would allow me as a member - Groucho Marx
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 4:01 AM
Points: 1,113,
Visits: 716
|
|
This just underlines the 'never use select * from... in a view' rule. I've been bitten by this parachuting in for a quick fix before.
Say you realise a need to include an extra column in a table for some purpose and do this. All seems good. Then you get a call 'such and such is not working'. What on earth? This was nothing to do with anything you have conceivably changed. Then the penny drops - a view was based on the table you have updated, tested and rolled out and included a dreaded 'select *'. This actually causes the columns to be output aliased with other column names - for instance productId might now be rebadged productDescription, and all columns shifted across.
The moral is check all view definitions when making structural changes to databases you are unfamiliar with, that have possibly been designed by those less knowledgeable.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Thursday, January 24, 2013 9:59 PM
Points: 1,354,
Visits: 1,299
|
|
| You got me on this one. I didn't know this would produce an error and according to the current stats on who answered it incorrectly, I'm not the only one.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 9:12 AM
Points: 1,167,
Visits: 646
|
|
Guessed, and guessed wrong.
Learnt something today. (Although who would use select * for a view in the first place?)
|
|
|
|