>>Most of the time Rushmore works good enough - but David is already walking the index directly,
>>obliterating any need for optimization. In some cases I found implementing that behaviour to be
>>measurably faster than relying on Rushmore in Scan and both being faster than SQL.
>>
>>My stab would be along the lines of:
>>

>>lnSel = Select()
>>SELECT curaccount
>>Set Order To xchange
>>If Seek("Y")
>>   scan rest while cchange="Y" for seek(clineid,"account","clineid")
>>	Replace cacc With curaccount.cacc, cid With curaccount.cid In account
>>   Endscan
>>endif
>>Select m.lnSel

>>
>>Which for me is more succinct - but as David is maintaining it,
>>his personal style is the one to weigh any measured speed differences against.
>
>I disregard much of what is called "style" or at least, I adopt the visual aspects of any existing style, so I have no style of my own to force on anyone. A do while is not style, it's a tool - we're supposed to use the right tool for the job. :) I could see going with your code, but I think you should also remember and reset the Set Order to xChange. The code I posted worked on a 5 million record table joined to itself with 5 records flagged and it took .017 seconds. It was fewer lines of code and as easy to follow as yours. :)

Hi Mike,

Scan rest is needed only in about 10% of my really hard working program - but there the effect is measurable.
Might have to do with being called often - so always rushmore check/setup is eliminated.
And about resetting the order: had it in first draft, but on comparing with Davids code,
he did not reset the order, so I reset only the alias I had added for anchoring the scan ;-)

>
>By the way, I notice there is a statement on the fox.wikis.com that says that update is arguably faster than seek, do while/scan. That's never been my experience. How about you?

Did not find that reference with one fast google, but SWAG:
Not if ALL the relevant indeces are in existance -
I guess SQL creating an index on the fly could happen to be faster than locating without index,
when in the replace cursor the index is walked, but lookup is not indexed.
But that is not a situation I would call relevant for my code ;-)

regards

thomas