Do you mean the equivalent of GETFLDSSTATE() and buffering?

That's precisely what I mean. If you use a layered approach, an entity passed between layers does not support change tracking. So you need to roll your own. Either that, or you need to leave it connected until you finish with it.

I'm saying this purely from a NET perspective. The same criticism could be directed at a VFP view- if you pass data between tiers, you can't send the view cursor so you need to do work to manage change tracking. You can use VFP's disconnected features, but in Linq you'd use SSCE (one day ;-)) so it's a different argument.

My guess is that MS will add some sort of change tracking at an entity level before long. Until then, it's difficult to argue entities over typed datasets for a tiered app.

I note that some NET luminaries don't seem to use the typed dataset's change tracking, preferring to roll their own. Presumably there's more to it. I have a feeling that some people handle change tracking in a SP(!) i.e. pass everything to the backend and let it handle it, but lets wait and see...