SELECT *

[Wes Groleau]

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.
-- Samuel Butler, 1612-1680

[Roy Harvey]

I agree with you up to a point, but there are pitfalls.

Don't forget that if the SELECT * is in a stored procedure or a view,
the * is resolved into the columns when the procedure is CREATEd or
ALTERed. If you do not remember to re-ALTER them after a change to
the underlying table they will not reflect the current table
structure.

Roy Harvey
Beacon Falls, CT

On Tue, 20 Feb 2007 02:44:58 GMT, Wes Groleau
<gr**********@freeshell.orgwrote:

>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?

[--CELKO--]

>For that last step, SELECT * is the sensible way to go. <<

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?

>If you really do want everything, why force yourself to have to edit the select if ever a column is added or deleted? <<

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.

[Erland Sommarskog]

Roy Harvey (ro********@snet.net) writes:

Don't forget that if the SELECT * is in a stored procedure or a view,
the * is resolved into the columns when the procedure is CREATEd or
ALTERed. If you do not remember to re-ALTER them after a change to
the underlying table they will not reflect the current table
structure.

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, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx