I have seen 2 notable reasons to stay away from select * if possible:
1. I have come across several issues with the schema changing in a
database and the changes where not reflected in a query that had select *
(legacy code). This can make the display layer break in strange ways when
t
Again, this is going down the template cache and query cache routes, in
trying to solve Duncan's problem with his CFQUERYPARAM error. Please do tell
us, Duncan, if it's just the SELECT * or if indeed the problem remains even
after that.
But the points Andrew makes before are indeed often valuabl
Well, sure, like the point about Select * being bad when you select more
than just the columns you need, so too is the benefit of CFQUERYPARAM (from
its performance perspective) only valuable for databases that support bind
variables (or what SQL Server calls parameterized queries). I'm sorry that
Andrew, I didn't say anything about SPs, nor did I (or would I) argue
against them. In fact, there's nothing in my reply nor in your note I was
replying to that discussed them.
In my note to you (which I'll assume you are replying to here, since you
didn't include it but I did offer two last nig
So, are you saying that removing the "select *" does or does not solve the
problem? I just want to know where this thread is crossing from solving your
problem to discussing the broader issue of "select *".
I'm actually surprised to hear that you would ask for a spelling out of the
reasons for wh
This may be a good place to point out that there is a free service
(mail-archive.com) which serves as a place to archive and provide search/web
interface for mailing lists. Now, with cfaussie using googlegroups, one may
ask, "why bother", but I'm just answering the question that Steve may be
asking