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

OK...


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

NO, you don't need a lot of code. It is all about iterating though a collection - in this case, two collections. A collection of fields on a recordset object and a collection of parameters on a command object. 20 lines of code - tops.

As far as the whole C vs non-C code thing, I don't see that as being relevant. The fact is, you cannot use SP's for updates when updating via a RV.


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

Not a rare situation at all. For example, lets say that I need to update a Tx table everytime I update a table. Yes, I could do this via a trigger and standard audit trail stuff. However, there are other reasons for doing this. I have seen folks try to overload a view to do this - and fail. With a SP - I can wrap the whole process in a transaction - update the underlying table and update the Tx. If the whole thing works, the Tx will be committed. If it does not work, the whole thing gets rolled back. The deal is that I can isolate the required code *in* in the SP. Best of all,the client never has to know about the Tx file at all - it is buried inside the SP.