From: "Helen Borrie" <helebor@...>
<<
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.

>>

I agree here, since the question was specific about it. I am only arguaing
about your advice on not using SELECT *, see below.

<<
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".

>>

I still don't agree with this premise. Just because I know SQL (which I do),
doesn't mean I need to write out a list of 50 fields in an SQL statement if
I need them all. Granted, when only a subset of fields are needed, I always
write the specifics, but, when all or nearly all are needed, I see nothing
inherently wrong in including all fields with a wildcard (*). It's not
laziness, to me, it just makes sense. If you need all fields in a select,
why not? The only possible reason I can see would be that another programmer
could see the fields of the table without looking into the database
directly, as you stated.

To me, this is the same type of argument as not using goto's or exit's or
break's. There are times when they are useful, not all the time, of course,
but sometimes they can improve the flow or logic of certain situations. Just
because you can do something different, doesn't always mean you should. I
consider it more of a personal preference than a "don't ever do this" type
of scenario.

Woody (TMW)