At 08:31 AM 08-05-02 -0500, you wrote:

>From: "Helen Borrie" <helebor@...>
>
> > Specify your output set's degree by providing a column list to your SELECT
> > clause. SELECT * is not recommended practice for serious work.
>
>
>OK, not to start a flame war here, but why? I really can't think of any but
>a select (pardon the pun) few reasons when exact field order matters. Any
>other time, field order has no bearing on a program using data. I have never
>had a reason to worry about field order through all the years of working
>with databases. Why have the hassles of going through all SQL in a program
>whenever a field is added, deleted, renamed, etc. and risk bugs whenever all
>or most fields are needed in the query anyway.
>
>Saying that SELECT * is not recommended for serious work is a broad
>statement that should only apply to few, if any, situations, IMO.
>
>The real danger, AFAIAC, is relying on field order instead of field names.

I agree with your point about "relying" on field order. However, this
questioner directly asked how he could guarantee to get a known order - I
think he mentioned he was importing from some external source.

However, I stand by my contention that select * is not recommended for
serious work. To me, serious work involves code that is easy to
troubleshoot and maintain, both client-side and server-side. There is *NO
WAY* that select * helps with that. No flame war - it's a fact of
existence in our trade. Select * tells me that the programmer doesn't know
enough about SQL, at least in the Delphi world where I work. "Queries? no
worries! just do select * and it's almost as cosy as a TTable".

regards,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________