(note: recordset object = query result set request.form("X") = FORM.X request.querystring("X") = URL.X connection object (~ sort-of) <cfquery> etc)
WHAT NOT TO DO (in classic ASP and ASP.NET)
if you use a recordset value more that once on a page <%= rs("fName") %> dump it into a local variable first and then use that (prossessing and memory issues)
No need. In fact the query object in CFMX totally outclasses most any language in terms of ease of use and functionality. By default the query object is local to the page -- it's not like instantiating a COM object and calling on it constantly.
Look into the attributes cachedwithin and cachedafter -- enjoy these, only CF has them.
Read up on query of queries.
same thing for request values: read once into a local variable (same reasons)
Both form and url scopes are effectively local vars.
don't store connection or recordset objects (or any objects really) in session or application scope (memory and threading issues)
No problem with this either. The query object is just another variable type. You can happily stored them in shared memory. Read up on dynamic query caching.
fastest/best way to process a recordset: read into a 2D array first (set arr = rs.getrows()) and then use an inner loop (fields) and outer loop (records).
Totally uneccessary -- the query object is already optimised. (And people wonder why ASP is painful)
don't build results into strings to output (eg in loops). output within the loop (memmory issues copying the data - except if you use the asp.net stringBuilder class)
Not sure what the memory issues are even in ASP. Is this a locking issue? Generally you output directly in CFML but you can also write to strings and output strings -- no memory issues that I can think of in CFMX.
if/then/else (defensive programming) uses less resources (memory, processing) than Try/Catch
I don;t think this is true of CFMX though I may be wrong. I suspect that try/catch is faster if the exception is rare. That is, if there is no exception it is quicker than the conditional logic, and if there is an exception it is slower than the conditional logic.
declare the number of array elements up front (have a guess first) instead of resizing dynamically (memmory issues copying the data).
This is not required in CFMX. In fact I'm not sure you can nominate a size of array up front in CF.
executing StoredProcs are always faster than executing inline SQL (in the code) - for the same query
This has little if anything to do with ASP/CFMX I suspect. Stored Procs execute faster on the db server cos they are precompiled.
Hope that helps,
-- geoff http://www.fullasagoog.com/
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
