>So you would create local updatable view, run the processing against that, and then tell VFP to send all the changes back at the end? If I have 1000 records updated, that's going to create one helluva SQL update statement to send back to the server. Shouldn't I get just the keys, and then do one record at a time?

I guess it depends. If you just get the keys, then requery for each record, you are still pulling more data over the while (the keys, and then each record). Plus, I think there will be additional overhead. Rather than getting everything at once, you are getting it a little at a time. You are still getting the same data, but SQL Server has to process 1000 requests, rather than just 1. It may not be much overhead, but at least some.

As far as the update process goes, one at a time may be better. It depends on how you want to handle a failed update. What if you process 10 of the 1000 records, then the 11th update fails? Do you stop the process, or continue? Do you need to use a transaction, and rollback the first 10 updates?

I have been doing some testing here on my local network (not a production environment) and doing a TABLEUPDATE() on 320 new records, 30 some fields, works very quickly. Then again, I am the only one on my network. < g >