Hi Randall,

I finally re-indexed the table in question (created two non-structured IDX files) and also used select into array solution. No more RECORD IS OUT of Range problems...

I really can not spend more time on this problem now, I had to test if the data match and I also have to meet with a customer today...

>Hi again, Naomi.
>
>>The strange thing, that I don't understand, is that it looks like my command set order
>>to 1 is simply ignored.
>
>I know, and this is what's bothering me. I agree with Nigel's solution.
>Just use a cursor, and now you don't have to worry about
>the pointer being changed. A simple and elegant solution.
>
>>Right before the ENDSCAN command I have
>>SELECT comision
>> SET ORDER TO 1
>
>Hmmm. In this instance, is 1 a cdx or idx file?
>I wonder what would happen if you actually named the file in the
>code?
>
>>GOTO m.iRec && Return back to the record
>>WAIT WINDOW "Return to the " + TRANSFORM(m.iRec) nowait
>>and then replace next 1 ...
>>
>>
>>I added wait window for myself and it's being executed. I do go to the right record
>>(originally it seems, like I even was not on the right record,
>>
>>since iRec and recno() didn't match).
>
>I'd be willing to bet a dime that iRec is lower in value than RECNO().
>
>I'm stating to think that SCAN has it's own idea of where it thinks
>the record pointer resides. That is, that dog ain't hunting until
>the next iteration of the SCAN loop, or any INSERT, UPDATE, etc. events
>change the pointer, yet SCAN refuses to notice the change, even though
>you're telling it where it needs to be via GOTO.
>
>>I may add wait window Order right after set order command, but it's very weird...
>
>If you have the time, Naomi, please mess around with the original a bit and
>let us know what you find out. I'm starting to sniff a VFP bug, unfortunately.
>
>
>Regards,
>
>Randall