Dan,

I believe that a WHILE disables Rushmore in any case, making it another reason to change to something else.

Good luck,

Jim N

>>>If the for is based on a field which is indexed that will still be optimized, correct?
>>>
>>>In the example I'm using fields with a primary index.
>>>
>>>I could use the and but I want the loop to end as soon as i hit a !llTableUpdateOK.
>>>
>>>The piece of code I'm working on would have 4 exits, I could use the go top or I could just use the and which would mean the entire table would be scanned.
>>>
>>>Which would be the best?
>>Correct it would be optimized.
>>"Best" is the hardest question of course :) I vote for "exit". Yet as always many more ways might be implemented to achieve this (one tableupdate with (.t.), getnextmodified() etc).
>>At least instead of "go top" what about setting order to "iInvoiceHdrId" and replacing "scan for" with "seek"+"scan while". Seems like I'm stuck with old days before Rushmore or paranoid to optimize myself :)
>>Cetin
>
>I think I'm going to go with the and !llTableUpdate. I should't lose to much performance. Thank you for your help.