> call them with CFSTOREDPROC rather than just CFQUERY.
How about a function or custom tag that makes all the extra keystrokes
of cfstoredproc unnecessary without eliminating any of the power of
them? :)
> 2) Learn what @@IDENTITY and @@ROWCOUNT mean, or better
> yet, what Scope_Identity() is (we use MS-SQL). If you
> write an insert process that involves selecting the
> max(id) out after the insert, walk out of the room
> immediately. I don't care if that's in the CF book under
> CFTRANSACTION. It's not best-practice and anyone who
> really knows CF knows it.
And @@IDENTITY doesn't guarantee the value you want because it's not
thread-safe. SCOPE_IDENTITY() was introduced in MS SQL 2000 with
little fanfare, so few folks are aware of it, but it is a necessity if
you're writing SP's in SQL2k that need to return an inserted identity.
> 3) Learn how to write cursors. It comes in handy.
Very much so in some circumstances.
> 6) Learn the dos and don'ts of CF in server farms
> (i.e. shared scope variables)
Is that a do or a don't? And why?
> 7) Learn best practices with CFLOCK
> (we're still with CF5, it matters)
Though you should try and have a deeper understanding of
race-conditions in general, and best practices with both CF5 and CFMX.
> 8) Learn best practices with cached queries and
> query-of-queries to take the load off the DB.
Although cached queries offer limited and quirky access to the memory
management. I tend to manage query caching myself rather than relying
on the CF Server's query caching. CF's native query caching does have
a couple of advantages - you can control the amount of memory used to
some extent in the CF-Administrator by setting the number of queries,
which isn't as easy to do if you write your own caching, and it
automatically expires the cache if the sql syntax changes -- which can
either be a benefit or a liability depending on the circumstance and
how well the developer understands cf's query caching. My bigger
problem with the native query caching is that you may never know how
many queries are in the cach (so you have to guess at whether or not
your app is caching more queries than are allotted in the cf admin),
and clearing the cache for a cachedafter query can be quirky/clunky
especially with CF5.
> 9) Know what fusebox is. If you don't even know the
> buzzword, you've been living under a rock.
Can we know what it is and still not like it. :)
> 10) Learn best practices in how to implement tracking
> routines and splitting systems up between production
> and reporting databases.
What do you mean by "tracking routines" in this context?
> 12) If you are used to Oracle or MySQL or something,
> learn MS-SQL too. I don't care if Oracle doesn't have
> identity or not. Know how to work with
> databases that do have them.
Identities are common enough that I'd say everyone should have some
understanding of them... developers should have a diverse
understanding of databases in general - some (if not in-depth)
understanding of the SQL standard, and at least rudimentary
understanding of the common/necessary variations in the more common
databases: SQL Server, Oracle, Access (yuk!), MySQL. Even though at
least in my case, variations in these db's are usually just
frustrations for me -- I wish SQL Server supported sequences and used
the standard name for their timestamp data type, I wish MySQL
supported views, I wish Access ... well, I'll not get into Access.
> 13) At least know a few gotchas like how
> CFLOCATION prevents you from writing cookies.
> A lot of intricacies of CF have to be learned
> through the school of hard knocks. Most of us
> know these common things.
One would hope.
> I've had people come in for interviews who can't even
> script out a CREATE PROC script on a whiteboard without
> leaving off commas and making other syntax errors, who
> don't understand how to rely on default values like
> GetDate() on insert statements by not referencing those
> columns.
With CFStoredProc the only way to do that is to either pass a null to
the procedure or make sure the parameter is the last in the sequence
since the dbvarname attribute didn't work and then was deprecated or
removed from the documentation. I wrote a custom tag and a function
(which calls the custom tag), which allow you to execute a stored
procedure using a structure as its parameters which lets you chose
whether parameters not found in the structure should be discluded from
the cfstoredproc tag or passed as null values. The problem with
discluding them is that if you are passing values further down the
list of parameters in the structure, they also _MUST_ be dropped,
there's no way around it.
... more in the next message... <sigh>...
s. isaac dealey 954.927.5117
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
