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.

Yes that's true, but it's also true that NET is evolving rapidly and a new wave of innovation is about to strike. Pity the VFP developer who converts to NET today and re-does everything using (say) pessimistic locking and full-row saves in stored procedures and then wishes he/she had waited a bit longer for Linq or had looked more closely at ADO.NET 3.0 datasets. I'm not saying it can't be done today, I'm saying there's a new model in the wings so if you can, wait to see its features and price before you buy the old model.

Re pessimistic locking: I don't have any problem with KG's insurance example. As I've said, if I had to move to NET today I'd use typed datasets with change tracking and a semaphore/account registration overlay that can be added into any process with the click of a mouse. It's not something I'd want to have to revisit so I'd take great care to get it right from the start.

On a more insidous level: whole record updating seems to be the "unspoken" model most people carry in their head. 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.

So why did VS2005 add change tracking to the dataset? Why is Linq gaining change tracking at the entity level? In any case, if change tracking can be automatically rolled into the object you're passing with data, it's no longer a design issue. To further the sandwich metaphor- you don't have to bake the slices of bread every time you make a sandwich.

I've been very happy with VFP's RV for over a decade. RVs have been attacked by various people but I never realized they were doing full row updates every time, in which case the RV doesn't add much. Most of us did pessimistic locking in the FP days with scatter/gather memvar full-row saves, but it seems that some people translated that to the C/S scenario and never appreciated the change tracking and selective updates available for free when you use a RV. From what I've seen it can be just about as easy in a typed dataset, and presumably eventually in an entity, so were I to convert to NET, that's what I'd aim for unless somebody has far more compelling objections than those raised to date.