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

Now you're talking about Code specific to the data controller vs. the actual Stored Procs aren't you? Either way, the stored procs themselves can be a large body of code. Not that a large amount of code really matters much, especially when a wizard generates it.

> The fact is, you cannot use SP's for updates when updating via a RV.

Sure you can. I'm not sure why you'd want to, but you could use the RV for data retrieval and data entry, then take the dirty data from the RV and send it back with SPT/SPs.


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

Me too. OK, let's forget about rare and call it a bad design choice.

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

And you can't do this with RVs? Sure you can.