>>I have inherited some code which does UPDATEs within a SCAN loop and we're finding not all records are being processed.
>>
>>My testing seemed to lead to the following conclusions on where the record pointer will be after an SQL UPDATE command.

>>UPDATE myTable SET myField = value WHERE condition

>>If condition is optimizable (doesn't seem to matter if fully or partially) then the record pointer will be at the last physical record which meets condition
>>
>>If condition is not optimizable the record pointer will be at the last physical record in the table.
>>
>>It doesn't matter if the index used to optimize the query is ASCE or DESC.
>>
>>It doesn't matter if there is an active index on the table.
>>
>>I'm pretty sure I know how to fix the code,
>
>...by making it independent of recno()...
>
>> but I'd appreciate somebody verifying my conclusions on the record pointer movement.
>
>I don't remember writing code which would make any assumptions about the record pointer after an Update, but what you wrote fits snugly with what I've learned so far about Rushmore: if it's optimizable, it means it reads indexes to find records to work on; if not, it still has to go through all the records. Set Order doesn't enter into equation in the case of SQL statements (select, update, delete, insert) as it's scoped to an alias and these statements usually open the tables again to work on them, under a temporary alias for the duration of their action.
>
>So it does make sense to me - it's as it should be.

Thanks for the reply.