Hi, John.

>Heck, if you can just fire data at a SP and update it all, that's far easier than creating efficient SQL updates and the rest of it. I wonder whether all this change tracking stuff is just Emperor's Clothes? Time to examine closely! FWIW I don't have a vested interest either way, I just want to make sure I'm considering techniques that a) won't be rendered obsolete tomorrow and b) can stand up to rigorous technical examination and c) can be reused in more than a single scenario. Which is the position for many VFP people considering NET today IMHO. With no baggage, people might as well focus on techniques that let them do it once, do it right. Bearing in mind that we've been told repeatedly that dLinQ/LinQ for SQL is going to offer cool stuff we'll like, it's pretty important for people who are deciding whether to go with NET at all.

I see someone else posted some links to information on change tracking in Linq to Entities. I had this one also in mind when I told you about this support:
http://blogs.msdn.com/adonet/archive/2007/03/01/object-services-write-less-code.aspx

Now, getting back to several issues around the thread (sorry for replying everything in one shot):

When you ask "why could someone prefer Entities to Datasets in April 2007", I would answer that for no reason, been the Entity Framework unreleased tehcnology, which could eventually came even after Orcas ships (end 2007~early 2008).

About this whole change tracking topic, I would say I have mixed experiences. Although it is good to have some conflict detection to be able to use it in certain circumstances for the user to solve them, I wouldn't apply this to every case. In many cases it is too hard to predict how data would behave and how it can or can't be partially updated, and sometimes the user doesn't have a clear chance to do it.

For most systems I worked for, either the "last one wins" or the "someone else updated this first, you failed" approach works ok because the chance of conflicting updates on a single row are very small, and in these few cases consistency is preferred.

That been said, of course there is a LOT of update operations outside of the standard CRUDs that can be constrained to a few specific fields but these should be acid in themselves (no change tracking applicable), like updating shipper code and shipping time, begin/end times for processes, stock quantities, price changes and so on.

Something interesting about the Entity Framework is that when updating complex entities which map to several related tables in a highly normalized schema, like updating a customer shipping address from the Customer main form, even if the update is done at the Customer entity level, will end up updating (for example) the Addresses table only, and not other tables involved, so the application wouldn't be sending lots of unneeded data to the server.

Of course, this is something you would normally handle on your own in a well crafted application, but it takes a good deal of effort to design, code and test it. The EF will do that (hopefully) for you in a total transparent fashion, and it would be very easy to adjust to eventual changes in the schema without changing the code (if the mapped entity remains the same).

This is like a VFP approach in steroids! You can write very expressive querys over entities (not the actual schema), you get typed objects as a result, and this is all very high level, so you don't have to struggle with lots of details... although you keep the chance to go to the low level details if you need it.

Best regards,