Hi john,

You're raising some VERY important points here, and I don't really see a satisfying answers how to implement flexible update management stategies like we have in VFP. It again confirmed my hunch that people don't really care so much about those.

I've been using local and remote views since VFP6 and it give me the flexibility to choose whatever updatescheme I'd like with just setting a few properties. If I see people here messing arround with code generators for SPs and working arround 'concurrent update issues', I really wonder whether people really are aming for the best approach, or for whatever works and deal with the consequences and limitations.

That is not to say that we don't have issues in VFP. Pessimistic locking remains something that invokes extra work, however with the flexibility in VFPs optimistic locking, there is less need to use it. As martin said, most people are confortable with the 'Last save wins' (on a field level, rather than record level though), or 'Prompt a user changed fields before you did' approach.

Walter,




>
>Thanks for the post. FWIW, I think I have a reasonable understanding of the latest CTP stuff and I feel very confident that Linq for SQL Entities (actually all entities) do not have change tracking at the entity level.
>
>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).
>
>So let me ask you: what should VFP people be doing in April 2007 if they feel pushed toward NET by MS's announcement? Should they start planning development using typed datasets when they've been told since 2005 that dLinq will provide the cool features VFP people need? Or should they look at dLinq? Or should they stay in limbo with competitors/customers trashing VFP as some have reported? Or what?
>
>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.
>
>Why do you suppose the concept of optimistic locking/targeted updates ever appeared let alone flourished? ;-) I think many VFP people use "last one wins" except only for fields that are actually changed- which is fair enough. I suppose this was made easy by the VFP view since it worked that way. ;-) But moving back to a scenario where stale data may overwrite new, or a complex save may fail because somebody else saved a trivial change to an irrelevant field? It seems a really bad idea IMHO. Easier for the developer, sure, but that's not a good enough reason IMHO.
>
>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.
>
>That might be so if you remain connected. Do you only ever develop 2 tier apps- you don't pass chunks of data between tiers? If VFP are considering NET in April 2007, would you expect them to adopt a more layered approach?