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 < matthew.nichol...@soltech.net> 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* > > *(p) 404.601.6000, Ext 233* > > *(c) 770.833.5326* > > *Yes. We can get you there.* **** > > ** ** > > *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Cameron > Childress > *Sent:* Wednesday, November 02, 2011 2:49 PM > *To:* discussion@acfug.org > *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 < > matthew.nichol...@soltech.net> 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***** > > *(p) 404.601.6000, Ext 233***** > > *(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>
