>>I doubt it'd be faster, except when you're calling a stored proc. If you're building the SQL in VFP, then passing it on, I wouldn't expect the performance to be different. SP is certainly a lot more flexible for queries though.


> Mike, what exactly are you saying here. John stated that a SP would be faster for a SP. You then said you doubt it would be faster, except when you are calling a SP? I think you just agreed with John here...

Totally bunk response on my part. I read the SP as SPT when I was replying.

> What would lead you to this conclusion. For updates, you have to populate parameters and pass them to the backend, and then invoke a SP. On the client, you are still preparing a SQL Update that still has to be rendered to the server.

You have to run a lot of code on the client side to do that, and, unless you want to really do a lot of checking, you have to just go ahead and include every field. With a remote view the code is created and assembled via C and it knows how to skip the fields that haven't been changed.

I don't know how it compares to calling stored procs, but in the tests I've run, generating this SQL on the client-side, then sending it up via SPT is slower than remote views.

> And, if you have multi-table updates, a SP is almost always going to make that process more manageable...

Why? No one in their right mind (except in rare circumstances) tries to update multiple tables from a single remote view. The general rule is one updatable view per table. A couple of SELECTs and TABLEUPDATES() wrapped in a transaction doesn't seem much more difficult than a couple of Stored Proc calls wrapped in a transaction.