Never say never.....

One of my applications loads a huge amount of data from a text file,
sifts through and discards much of it, and rearranges what's left.
Finally, it is added to similar data from many other files.

For that last step, SELECT * is the sensible way to go.
If you really do want everything, why force yourself to
have to edit the select if ever a column is added or deleted?

--
Wes Groleau

He that complies against his will is of the same opinion still.

[quoted text, click to view]

No, it is lazy and dangerous, not at all sensible. Hopw hard is it to
use a text editor to get the column names? Or to write comments?

[quoted text, click to view]

Because if you do not have control over your software, you are at the
mercy of every re-compile or change to the tables and do not know it.
And machiens have no mercy -- they will do exactly what you have told
them to do.

A good programmer writes code that protects itself.

Roy Harvey (roy_harvey@snet.net) writes:
[quoted text, click to view]

True for a view, but since SQL 7 no longer for a stored procedure.

In my opinion, SELECT * from a temp table created in the same stored
procedure is OK, because you have full control. But else, it's a no-no
in my book. The database designer adds or drops a column, the result
set changes, and the client breaks. (Yes, if columns are explicitly listed,
and you drop a column, the procedure breaks. But that can be discovered
by building the database from scripts.)


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at