Thomas --

Thanks for the extensive response!

In my case, my CustSummary file is really small ... less than 1,000 records, and the CustNumber field is a four-byte integer. I'm not really concerned at all with processing on this file, or the other similar files (other than SalesSummary).

The INLIST looks interesting, altho it is possible for the user to select as many entries to go into my cDrillDown as desired -- so they could go past 26, although that would be highly unusual. In any case, I don't think that's the issue you're getting at.

So, I think I'm beginning to get it. It seems like you're saying that if I have a list of CustNumbers in an indexed cursor,

Select blabla from SalesSummary where CustNumber in (select * from cList)

is not as good as

Select blabla from SalesSummary join cList on SalesSummary.CustNumber = cList.CustNumber

Would you agree with that?

>Hi James,
>
>>Actually, I can create any number of cursors to filter from cDrillDown -- it's a teensy cursor where an additional row is added each time the user drills down another level. In only very unusual circumstances would it have more than five records or so in it.
>
>Now that may be very important information: sometimes it is faster to create a list for inlist() as a filter clause:
>meaning for you to "scan for Depth=x" those cursors before, adding the Left(DrillValue,y) onto 2 strings then put as a filter like

>lcCustClassList = ""
>Scan for
>   lcCustClassList = m.lcCustClassList  + "," + Left(T_1.DrillValue,20)
>Endscan Depth = 1
>
>lcCustClassID = ""
>Scan for
>   lcCustClassID = m.lcCustClassID  + "," + Left(T_1.DrillValue,20)
>Endscan Depth = 1
>
>Select cs.CustNumber as FustNumber from CustomerSummary cs;
>     Where Inlist(cs.ACustClass &lcCustClassList) ; && needs Index on ACustClass
>     and   Inlist(cs.ACustID    &lcCustIDList) ;    && needs Index on ACustID
>     Into Cursor T_C ;
>     Group by 1 && are they distinct already ? if so, eliminate the group by!
>
>Select {some_fields} from SalesSummary   ;
>       join T_C on FustNumber = CustNumber ;
>       Where Between( period, m.lnFirstPeriod, m.lnLastPeriod) ;
>       into cursor cBrowse readwrite             ;
>       group by {some_other_fields}
>
>

>Benefit here: Rushmore could build a double filter through those Inlist() without creating intermediate table. If those drilldown cursors are really that tiny and you never grow to more than the 20-odd maximim parameters, this might be faster - especially if CustomerSummary has oodles of data for each subfilter which would have to move into a temproray table otherwise.
>
>>Now, as for JOIN vs IN ... (first of all, I'm sure I don't even understand what JOIN does without something on the left, and I find the documentation particularly opaque) ... If I have a list of, say, 100 customer numbers and I want to select all records from a large table that are in this list, that using the JOIN syntax is faster than IN?
>
>Usually yes - but in my example I *assumed* that the filtering cursor is distinct, which you must check first and perhaps add a group by 1 as in this example. If that is not the case, you must make it so.
>
>I also prefer the In() syntax for clarity on most first drafts, but Join Syntax is often the fastest way of doing things if you cannot filter on rushmore alone like above. Just be sure to realize that you are exchanging flexibility (no. items possible in drilldown "Select") vs. speed if you go for "Inlist".
>
>HTH
>
>thomas