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.

>
>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