Hi, Walter.

>>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.
>
>Another example is an item table that contains redundant columns for stock tracking. If a user changes description of an item, while someone of generating packing lists of order, you don't want the redundant columns to be reset to the value of what goes with the description change. We as VFP developers have been very comfortable thinking in the being very flexible in update management. Even with REMOTE and LOCAL views we remained to have this flexibility. I hate to throw this overboard as it really affects database and application design, which should be your last resort.
>
>IOW, if I'm going to write an application in .NET, I'll definately search to the way we handle updates within VFP: "Last save wins" or "User changed a field before you" on a FIELD level rather than ROW level. The latter causes too much pain for the way database development is supposed to be done.

I guess the main difference in VFP and .NET is the latter is lower level. While in VFP you have a lot of declarative stuff that does things for you, in .NET you have the plumbing but you have to build some common functionality to suit your needs. Thus, while you have FileToStr, Import or Remote views in VFP, you have to write several lines of code to get to the equivalent stuff in .NET. The value proposition is different there.

Naturally, you'll write reusable components for these tasks, and then you should get to the same or a similar level of productivity. This can be perceived as a drawback, but it also gives you the chance to control behavior beyond what VFP does. In VFP you're usually locked with what's built in. Granted, what's built-in is pretty good for many purposes, but I guess we all had moments in which we found ourselves wishing we could change something about the way some command or functions worked, but this was impossible.

Not, .NET forces you to build your own stuff or get something someone else built which fits your need. Many people coming from a VFP background had implemented libraries resembling (or improving) on VFP strengths, like Mere Mortals or StrataFrame -let alone the more challenging effort Samuel David is taking.

The intent of LINQ is stretching up the languages level so you have more declarative power, but without losing the chance to manipulate everything at the lower stages. And, of course, in the context of a safer environment where you have type checking and many other benefits. I know you're fond of dynamic languages, too. And they are coming in the DLR, which is a dynamic layer on top of the CLR (on top of which IronPython, PowerShell, the JavaScript engine and more are been built).

I know the .NET environment doesn't have everything a VFP developer wants, but they are not making this for VFP people, but for everybody else, and I think we in the VFP community can't be so arrogant as to think that we are the only community knowing how to handle data. We really have a good deal of knowledge, and we can contribute a lot, but in my opinion, we shouldn't underestimate what the .NET designers at Microsoft (who are not kindergarden kids at all) are doing, but trying to understand the pieces, how they fit together and -yes- trying to find weak links and communicate them in a constructive way.

Best regards,