SELECT *

[jcaley]

Hey,

I know that using SELECT * is bad practice.  But let's say that your main query is cached and only selects the needed columns. You then have Query of Queries assigned for different resultsets.  It's not bad practice to use SELECT * for these Query of Queries is it?  I am already limiting number of columns retrieved by the original query.

Thanks!

[ilssac]

It is probably less agrevious then using select * against a true database, since I suspect the caching issue that can cause very hard to track down problems when a database table is changed will not happen with the query-of-query memory version.

But then if you care to take no chances I think you can get the exact same affect using the query.columnlist of the original query.

I.E.

<cfquery name="myTest"...>
SELECT aField, bField, cField
FROM aTable
</cfquery>
<cfquery dbtype="query" name="myProof">
SELECT #myTest.columnList#
FROM myTest
</cfquery>

[jcaley]

Thanks. I like your suggestion!

[Adam Cameron.]

I know that using SELECT * is bad practice.  But let's say that your main query is cached and only selects the needed columns. You then have Query of Queries assigned for different resultsets.  It's not bad practice to use SELECT * for these Query of Queries is it?  I am already limiting number of columns retrieved by the original query.

I would say a QoQ would be one of the few situations in which I don't mind using SELECT *, because I probably would have already specified the column list elsewhere.

Editorial comment:

Logically speaking, whether or not one can do SELECT * with a query... the code that goes on to use the recordset is generally going to need to specify the columns that it uses.  It's fairly rare to have business logic that takes an unknown variable number of columns, and performs a standard process on all of them (so like looping over the query row by row, and then within that looping over its columnlist, isrrespective of what the columns might be).

So if your business logic specifies a set of columns, your data retrieval should likewise be being selective about what its fetching.

--

Adam

[jcaley]

In this case , I am trying to maximize code reuse. I have a bunch of processes that generally need the same tables, info, etc. Just the criteria and any additional subprocessing (Q of Q) changes. So depending on the args sent to a method that contains the main query, a variable number of columns could be selected, tables joined, or fields in where clause can occur. I just find that using SELECT #Something.columnList# is very handy for furhter data processing or outputting to html, excel, etc. It's fast and offers consistent results.