Here is a link to the most recent version of the relevant Books Online article: http://msdn.microsoft.com/en-us/library/ms187821.aspx. It's the same aas the one in the explantion, but without the explicit version number added. (Why do people so often use links to older versions when the question is not about that older version? Why????)

The true danger of using SELECT * in a view becomes apparent if, after adding that new column, the original column is then dropped. The view will still return data, still use the name of the old (no longer existing) column, but return data from the new column.

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

(was thinking if the 4th option will come true in future versions, would be cool, and then thought again.. setting auto to everything is not a acceptable way to go, but it would be a nice feature and a lot to consider before really using it

Using "schemabinding" and "select *" ... I do not feel comfortable using it.. i create VIEW with the specifying column names, and if needed, then alter the view to suit the new needs and modify the code to the new adjustments. Earlier i had views with select * in one of the web projects and then later I changed them to the column specifics.. and by doing that whenever it is needed I kind of gained control over the objects by knowing which object needs modification and which doesn't and i was knowing each and every VIEW object which are the tables it refers.)

ww; Raghu--The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.

but even if I did... If I had to refresh the view, I'd typically just alter the view and leave the code as is... that works too, or did... I haven't written a view with SELECT * in it since before SQL 2005