Hi Jim,

SYS(3054,1) reports the optimization as "full", even though I would tend to agree with you about Rushmore not really having any effect here. It just seems to me that there should be some way to get VFP to do the order by after the selection set is made and retrieve a sorted list in a speedy manner.

I guess I'll just have to do a secondary select or stick with the index after the select.

Thanks,

Steve

>I would say that, despite your existent TAGs, Rushmore is NOT operating here at all! You don't have a WHERE clause (or a join) to give Rushmore anything to work with.
>
>The command without the ORDER BY would no doubt return faster, but I don't think that it would necessarily have finished by the time you get SOME rersult back. Without the ORDER BY any record will do as some result getting back to you.
>With the ORDER BY you force it to get all records, then sort them, THEN return the result to you.
>
>At least that's the way I see it.
>
>Jim Nelson
>
>>>>>
>>>>The following query takes about 36 seconds:
>>>>
>>>>

SELECT DISTINCT &lcField FROM DocsMast ;
>>>>   ORDER BY &lcField ;
>>>>   INTO CURSOR TreeInit

>>>>
>>>>The following code runs in less than 1 second:
>>>>
>>>>

SELECT DISTINCT &lcField FROM DocsMast ;
>>>>  INTO CURSOR TreeInit
>>>>
>>>>INDEX ON UPPER(&l_cField) TAG Sorted

>>>>
>>>>Why? Is there a way to get the result ordered without having to do a manual INDEX or wait for 30+ seconds? I gather that VFP is applying the ORDER BY to the entire table before applying the DISTINCT clause.
>>>