Collate is not new to VFP. It was in FP since 2.x (skipped 1.x so don't know if existed then). But Simon as you say "machine" it seems to be in its default. I suspect if the change is in "set deleted" and you have no tag for deleted(). Just having "scan for..." doesn't give much clue. It might also be the code between scan..endscan.
ie: How much does it take to execute :

select * from transact ;
  where transact.idate<=m.updtdate AND ;
      transact.itrancode="Q" AND ;
      transact.ilookfordd="Y"

Cetin

---

>Oh, I forgot to mention that this has been working fine for about 4 years, then suddenly got really slow... that's why I thougt Rushmore might not be in effect
>
>>Thanks for getting back.
>>
>>The command is like this.
>>
>>SCAN FOR transact.idate<=m.updtdate AND ;
>> transact.itrancode="Q" AND ;
>> transact.ilookfordd="Y"
>>
>>...
>>
>>ENDSCAN
>>
>>The table has (among others)indexes on idate and itrancode.
>>I've never heard of set collate before, (There's nothing in my manual)
>>but set ("collate") yields "machine". I don't know how to find the collate setting of the index. Is this a 2.6 thing?
>>
>>>Hi Simon,
>>>
>>>>I'm having a problem whereby a SCAN is taking a *VERY* long time, and I suspect that this is due to RUSHMORE not being used.
>>>
>>>Can you post the FOR condition of the SCAN loop as well as all the indexes set up for the table? Also, make sure that the current SET COLLATE setting matches the collate setting of the index (IDXCOLLATE()).
>>>
>>>Christof