I certainly agree with you there, David, but I am wondering about something "external" (some updated or new facility of MS' quite recently delivered) which may be 'attacking' the same relative area of ram where VFP's SEEK() code lives.

It just seems like more than coincidence that a fairly aged and reasonably documented and straightforward command should suddenly be experiencing weird performance like this.

Cheers,

Jim N

>Jim,
>
>The probability that this is a newly discovered VFP bug is much much smaller than the probability that it's programmer error or a corrupted index file.
>
>>It does seem more than strange, though, that 3 separate problems of this nature have been reported within the last week to do with the SEEK() function (2 here and 1 on MS site).
>>
>>It's almost is as though something *recent* has found a way to mess up a piece of VFP.