>Hi Mike,
>
>>Regarding Thomas' reply:
>>Sometimes, you just can't beat xbase style. I really think the old do while not eof() stuff is not all that readable. You can get the same result more succinctly:
>>

SELECT curaccount
>>scan for xchange="Y" and seek(clineid,"account","clineid")
>>	Replace cacc With curaccount.cacc, cid With curaccount.cid In account
>>Endscan

>
>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. :)

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?

>
>>
>>Regarding my reply:
>>I remember reading that the flock should speed the update quite a lot, but that isn't scientific of me at all. A quick test shows the flock does not help. In any case, VFP doesn't lock the whole file, just the header.
>
>IIRC flock() helps more in cases when the code utilizes insert SQL/append in loops.
>Using the table exclusive *sometimes* speeds up replace operations -
>perhaps delaying index updates to cdx, if updates happen to an indexed field.
>Repeated measurements by myself, but not scientific testing behaviour into the reason of it ;-)
>
>>
>>Your code sample has a PUBLIC cmemvar and later on a ?cmemvar. After the ?cmemvar what purpose does the cmemvar variable serve at the command window? My point is scope variables to the piece of code and rarely if ever public.
>
>I am all with you on minimizing public and private memvars usage to areas where they are really needed.
>
>This is one count where my interpretation did not "tick" on public, but on the name of the public memvar:
>In most of my larger apps I have a magic public cSys3054Result to use in any SQL somewhere in the app,
>with enabling/disabling methods on my goApp.
>
>Some background to this: when MS was asking for vfp enhancement ideas,
>I tried to push having the option to pipe into properties as well,
>sys(3054, 11, "SqlLogger.cSys3054Result") for instance - was not done,
>but my alternate approach was implemented, resulting in Sys(3092).
>
>My hope back then had been to have a hook via assign-method
>on SqlLogger.cSys3054Result to filter out any long-taking query.
>Ancient history...
>
>regards
>
>thomas