SELECT *

#1

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

#2

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
<groleau+news (AT) freeshell (DOT) org> wrote:

Quote:

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?

#3

Quote:

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?

Quote:

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.

#4

Roy Harvey (roy_harvey (AT) snet (DOT) net) writes:

Quote:

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, esquel (AT) sommarskog (DOT) 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