Hi,
>scan for ctype=cvar1 and nnum=nvar2
>...
>endscan

>Recently this scan became very slow. I've indexed the table in cType and nNum to optimyze speed but it does no work...

You have received the best technical advise to speed up vfp CODE - but such advice should mostly be felt when calling such constructs repeatedly. If there is a large slowdown, I'd look for other reasons, especially more on the HW side of things.

First thing (if the app logic allows it) is to pack the table: If there are many deleted records, the vfp engine will check the deleted records as well (if they are not "put aside" via binary index on deleted() in your old code, won't help in Cetin's optimized version). Tables bloated with deleted recs will give you bloated times<g>.

Check if the amount of physical RAM is still the same: when a machine is moved, one or more RAM strips might loose connection, leaving a RAM starved OS swapping like mad.

But if the slowdown is more on the order of 3-5 fold, I'd check the disk and the way windoze adresses it: windoze can scale down the access from (U)DMA to PIO if many errors are encountered with the physical disc. One of the signs is increased CPU-usage when accessing the disc as seen in the task manager, but best seen in the device manager for the disk controller. Bites me sometimes without any satisfying target to hit back...

my 0.02 EUR

thomas