>Jim,
>
>How do I know where in the array the record is sitting i.e. [4]?
The "4" in this case is the row of the query you want to change. The format is
"QueryName[ColumnName][RowNumber]" or "QueryName.ColumnName[RowNumber]"
So what you really need to know is the row number of the record in question - and
there are a lot of ways to get it.
The simplest way is to pass the row number as part of your update process (in the form
or whatever). You can then reference the values pretty much directly (there may be
issues with concurrant access or deletes however).
You can also, upon an update just loop over your query looking for changed records
(perhaps you've stored the primary key of all changed record in a list). If you're in
a loop then you can use the built in variable "CurrentRow" as your value like so:
"QueryName[ColumnName][CurrentRow]".
You can also access any column as an array (queries are actually stored as collections
of arrays - one array per column). So you could do
"ArrayToList(QuerName[ColumnName])" on the primary key - doing a listfind() for a
specific key will give you the position (and thus the row number).
There are lots of ways to do this... what works best really depends on your data and
how you'd normally determine which records are which.
What works best really depends on your data, however often its updated and used and so
forth.
Cached Queries have many benefits:
1) No developer locking is required, tho' I'd still put a named lock around updates).
2) Simplicity - one cfquery and you've got cache.
3) Query of Query functionality - very nice if you're comfortable with it.
4) Some built-in support not available with other data types (for example the "group"
attribute of CFOUTPUT).
However they may not be the best or most performant solution. Structures and Arrays
tend to be faster in general.
Structures can be much faster and getting at arbitrary data is a breeze... however
structures don't maintain order and can sometimes be slower when looping over them
Arrays maintain order exceedingly well and loop very quickly, but it can be a pain to
find specific records.
There's a lot of freedom with lists: there's a very rich function set and they're easy
to understand conceptually. However they can be (VERY) slow, lack structure, and it's
harder to update them than other options. (Although in some rare cases Lists are
actually the best possible solutions - outperforming structs and arrays).
In general I would look at our you plan to use your data. Will their be a need for
many, arbitray selection: Queries (and QoQ) are the way to go. Will you need to
constantly deal with single elements? Structures can't be beat. Will you always need
the full list in order? Arrays are you solution.
That's a simplification of course, but the concepts are valid.
One last thing however: in many cases you might spend a lot of time to use the most
appropriate data type but end up with a a LOT of code to handle things or a difficult
conceptual model.
If, for you, using a query means it may be a little slower but that you'll understand
it better than I'd use a query. I personally place a higher value on maintainability
than on performance.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics.
http://www.fusionauthority.com/signup.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
