You seemed to previously be arguing that .NET didn't have a way to do that unless you were "connected", unless I misunderstood you.

I feel sure I've already said this, however: it was stated elsewhere that datasets are rendered obsolete by entities. I decided to investigate. I found that dLinQ entities have no change tracking as soon as you disconnect from the DataContext, which you have to do to cross a tier. As you note, datasets need not suffer this limitation. Therefore why would you consider entities over datasets in April 2007, unless you can stay connected. Clearly datasets are not obsolete. MS (or at least a MS employee) has acknowledged the issue elsewhere (see previous post for link) and says it will be addressed.

I have no idea why people have interpreted this as "NET can't do change tracking". I'm wondering whether I'm the only person who has actually looked at LinQ and "gets" the distinction.

Since then I've learned that even those who advocate datasets apparently don't use the change tracking functions. So, I've tried to find out how they manage change tracking. One well-known author uses SPs that update every field every time and has rolled his own pessimistic locking system to avoid change tracking altogether. I'd be interested to hear your opinion of that. Why aren't these people passing datasets and using change tracking so they can reuse classes in stateless apps rather than writing something new? Is use of SP more important?