>>I can't imagine why anyone would want to send back an entire table to be updated if only a row or two has changed. Now, granted, I don't *do* field-level change tracking (but I could do it if necessary without too much hassle), but I *do* only send back changed rows at least.
>>
>>Hi, Bonnie....I don't think *anyone* has said they throw the entire table back, just for one row. I think this entire discussion has been about only passing back specific columns and the discussed need for two users to modify different pieces of data on the same row at roughly the same time. Since I think you and I handle the UPDATE proc in pretty much the same way, with default null parameters, any changes are, as you said, a matter of handling/checking the specific oolumns in .NET and only passing those up.
>>
>>Kevin
>
>This entire discussion has been basically worthless. There are column changed events on the ADO record set that allow for tracking changes at the column level as well as ADO's row state changed event. The enitre debate over change tracking and what to pass to the backend is a red-herring. The underlying intent is to disparage .Net and to prove VFP's superiority as a data platform. That's it in a nutshell.

I don't think so. No need to throw the baby out with the bathwater here.

To me this conversation has been mainly about VFP users trying to map in their mind what they have been using with VFP to .NET. If there are weak points in .NET, it should be, and it is, OK to say so.

Pertti