Hi John,
>Tom, I don't think there's any organised MS "plan". The timing of the announcement was highly unfortunate at the current state of affairs: VFP people who try to look at dLinq know as much as if not more than NET familiars, and it's got plenty of evolving to do yet.
>
>If it's at all possible to stay in VFP, IMHO that's the answer for now, even though competitive and customer risk has been created by the announcement. If people feel forced to move to NET, typed datasets seem the way to go WITH change tracking, though you might be inclined to start over once dLinq is a bit more complete.

the second part sounds too vfp sided to my ears <g>. While I know that you also were one of the early java birds and are not preaching vfp for everything, the line about "at all possible" is IMHO overdrawn. Currently about 80% of my work is in vfp and I have n problem with that as it pays quite handsomely, but part of that work could be in about every language I know - the bar there lies in recognizing the "business needs" quickly, reacting instantly to customer woes and finishing quickly. vfp helps there tremendously by the interpreter nature and overall integration, but in .net a framework approach would surely work as well, as would python, ruby, javascript or even php. Not hw taxing at all, I was called in because it already is in vfp and the app has grown to quickly for its own good. MY main task is refactoring / rearchitecting.

You might have noticed that I wrote wishing about a dbf compatible package including SQL queries and conflict managment on vfp's level for python or .Net before this thread started <g>. But I must also "confess", while I've used "changed field only on optimistic", in more than 50% pessimistic was a better fit. The more "business rules" are involved, the better pessimistic looks - and Kevin's example of insurance is quite correct for a scenario worse than hell for field change approaches. I KNOW - had to fix it once <bg>.

On a more insidous level: whole record updating seems to be the "unspoken" model most people carry in their head. That reaches from more automatic data entry jobs up to quite technical people writing specs. On large systems it is best to write the code according to such hidden models: even if top devs proof reaad their specs to be workable, not all devs are able to do this. The application gets more stable if such unspoken assumptions are followed ( less work to "educate" testers as well). No hard data (and loosely formulated <g>) but I am sure you have been in similar situations and know what I am writing about.

regards

thomas