Afternoon All!
It looks as though scoping the variable may have done it although I'll be frank, I'm not quite sure why. I also found the issue related to comparing ListFindNoCase() and ListContainsNoCase(). While I done it previously without scoping the variable with no success, once scoped, ListContainsNoCase() returned something other than 1. I'm not sure of the underlying reason for this issue as it was functioning perfectly up till about a week ago (according to the client). As time allows, I'll throw together a few tests locally and see if I can't pinpoint where the functions are breaking down. Thank you all very much for your direction! Matthew R. Nicholson SolTech, Inc. www.soltech.net <http://www.soltech.net/> (p) 404.601.6000, Ext 233 (c) 770.833.5326 Yes. We can get you there. From: [email protected] [mailto:[email protected]] On Behalf Of Cameron Childress Sent: Wednesday, November 02, 2011 6:00 PM To: [email protected] Subject: Re: [ACFUG Discuss] List Handling First this I see is to try scoping your "id" var: <CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) > If the value of "id" is remaining the same as the first query value, then it's always going to return 1 as the list position. You can also output the id value and it's list "pos" as a debug measure if you want... Either inline or using cflog or similar. <cfoutput>#id#:#pos#<br/></cfoutput> If that doesn't uncover your problem, shoot back an email. -Cameron On Wed, Nov 2, 2011 at 5:23 PM, Matthew Nicholson <[email protected]> wrote: I'm always happy to share an example of bad practices! :D All things said and done this solution is far from ideal, which is an understatement, but I'm always excited to hear options and opinions. >From a high level, this is the current process outlined below in code: 1. Stored Proc dbo.Orders provides data 2. QoQ qryAuto allows us to determine a subset of Orders that meet specific criteria 3. Loop through the QoQ qryAuto to perform specific processes against specific Orders 4. If the order doesn't meet those requirements, we then modify the list autoOrders 5. Lastly, the autoOrders is used to limit what we display to the User <cfstoredproc procedure="dbo.Orders" datasource="#main_dsn#" returncode="yes"> <cfprocresult name="Orders" resultset="1" /> </cfstoredproc> <cfquery name="qryAuto" dbtype="query"> Select * From Orders Where Blah Blah Blah </cfquery> <CFIF qryAuto.recordCount GT 0> <CFSET autoOrders = ValueList(qryAuto.id, ", ")> <CFELSE> <CFSET autoOrders = 0> </CFIF> <CFLOOP QUERY="qryAuto"> <CFIF Check1 & Check2 & Check3> Do all sorts of goodies <CFELSE> <CFSET pos = ListFindNoCase(autoOrders, id)> <CFIF pos NEQ 0> <CFSET autoOrders = ListDeleteAt(autoOrders,pos)> </CFIF> </CFIF> </CFLOOP> In the end, I was curious if I had just run headlong into an issue because of the use of lists. I will say, the list autoOrders shouldn't be "long long" ever as this process is supposed to kick-off continuously. But, if this is the heart of the issue then a redesign is obviously necessary. Thank you all again for your thoughts and insight! Matthew R. Nicholson SolTech, Inc. www.soltech.net <http://www.soltech.net/> (p) 404.601.6000, Ext 233 <tel:404.601.6000%2C%20Ext%20233> (c) 770.833.5326 Yes. We can get you there. From: [email protected] [mailto:[email protected]] On Behalf Of Cameron Childress Sent: Wednesday, November 02, 2011 2:49 PM To: [email protected] Subject: Re: [ACFUG Discuss] List Handling First, as to your actual problem with listFindNoCase() returning 1, I'd say show your code. There could be a number of logic problems causing this. However, I think you are going to run into another problem first. Because of the way CF handles lists, it's a real REAL bad idea to keep long lists and loop over them or do other things to them in code. The longer a list gets the longer your loop is going to take - not incrementally, closer to exponentially. ColdFusion treats a list just like a string, and when you ask for item 300, it first has to look for the previous 299 items before it gets to 300. When you ask for item 301? Yup, goes through all 300 again before finally settling on item 301. It's much MUCH better to use an array or struct or any other sort of structured data. A ColdFusion list is not structured, it's just a real long string. I've seen apps that take 60+ seconds to render a page that uses long lists. Once converted to arrays, that same page took <1 second to run. Your situation might not be as dire, but the longer your list gets the worse your potential performance problems are going to get. Short lists are fine, but I wouldn't want a 300+ item list floating around being looped over. In my previous example, the list was 4,000+ items long. Show your code or describe what you are trying to achieve and perhaps we can collectively help you find a better way. -Cameron On Wed, Nov 2, 2011 at 2:35 PM, Matthew Nicholson <[email protected]> wrote: Morning All! I could swear we had a discussion about this awhile ago (although I may just be remembering an article from Charlie's site). I'm experiencing a bit of a head scratcher in regards to lists and managing them. 1. Using a QoQ, we create a ValueList from one of its columns a. The ValueList is rather sizable list (400+ entries) of identifiers 2. We then iterate through the QoQ and do some logic 3. Should one of those entries (in the loop based upon the QoQ) not meet the criteria of the logic, we then remove it from the ValueList previously created ValueList Now, previously, I'd simply search through the list using; ListFindNoCase() And then delete the entry in the ValueList that needed to be removed using ListDeleteAt(). However, the rub that I'm experiencing now is that ListFindNoCase() which worked previously is now only returning 1 when the entry is found (even if it's obviously not the first entry in the list). Questions! * Have you all experienced similar problems with sizable lists? * Do you all know if there is an upper bound of the size of a list that can be handled by ListFindNoCase()? * Could this be related to the ValueList itself (the index is being the issue)? Thank you as always for your thoughts! Matthew R. Nicholson SolTech, Inc. www.soltech.net <http://www.soltech.net/> (p) 404.601.6000, Ext 233 <tel:404.601.6000%2C%20Ext%20233> (c) 770.833.5326 Yes. We can get you there. ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- -- Cameron Childress -- p: 678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf> | twitter <http://twitter.com/cameronc> | google+ <https://profiles.google.com/u/0/117829379451708140985> ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- -- Cameron Childress -- p: 678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf> | twitter <http://twitter.com/cameronc> | google+ <https://profiles.google.com/u/0/117829379451708140985> ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
