Using SEEk and REPLACE is very fast. It also helps to design the system in a way that reduces a REPLACE in a key field.

if lNewRecord
   append blank
   replace MyKeyField with MyKeyVariable
else
endif
replace ... all the other fields ...

That table update stuff seems slow and funky, if you want it to go - you gotta do it low! Binding also slows it down - Instead of binding, just assign the data to the value.

SET 2CENTS OFF

>Hello Bob,
>
>we also have this behavior!!
>
>I believe in general people not seem to fall over this because VFP is still very very fast, but performing a bigger amount of "table commands" makes applications slow down dramtically.
>
>We have no solution to this yet, but we have done a big serie of test including:
>Rushmore optimisation
>SET DELETED stuff
>VIEWS DBC lokal
>Trigger stuff
>SORTWORK,TMPOWORK.. settings
>Disabling Visusscanners
>different operating systems
>differnt clients
>SET Tablevalidate 0
>Differnt View settings
>Using remote views on local data...
>
>All these things and a bunch of more have not lead to a solution yet. Still our application slows down 100% (1/2 performance) in the moment a second machine logs into the application.
>
>All reserach leads to the fact, that the VFP Table Commands slow down!
>
>One more real strange behavior on this:
>We have EXE local and the data in the network accessing it over local views.
>
>When we start the EXE from 2 differnt machines we have the performance lack, BUT wenn we start the EXE twice on the same machine we don't have the performance problem.
>
>For VFP there can't be a differnce, so we are quite sure that this behavior comes from any kind of locking stuff on the server. But changing the server dind't make it for us ?
>
>In our case this is no problem with data on network, it only comes up with the second user logging it. Till then everything is fine, or lets say as expected.
>
>One more thing we also found is that at the moment we have the performance lack the same process in the application pulls about 10-times as much data down the network!
>
>So we are also still looking for a solution, open for any ideas.
>
>Marcus
>
>>I seem to be seeing a large degradation of performance in a FoxPro application as more and more workstations load the executable and
>>run it over the network.
>>
>>The degradation becomes severe when two or more workstations are running some data-intensive function.
>>
>>It is easy to get some part of the program to slow down by a factor of 10 in this way.
>>
>>Experimentation suggests that some of this is due to FoxPro checking the status of record and file locks, as the degradation increases with the number of users and especially with instructions that either perform a lock or update a table (REPLACE, APPEND,INSERT, DELETE, and TABLEUPDATE).
>>
>>I wrote a test application in FoxPro that executes a SEEK, gets a record lock in a free table and REPLACEs a value on that record.
>>It does this 30,000 times in a loop, using the same record each time.