Walter,

>>You seem to be very touchy indeed - like a twitching, itchy finger on the trigger of a gun.
>Touchy?? I don't think so.

I beg to differ - it is most apparent.

>Well before LINQ some prophets declared that local data processing was not so important. Data processing belonged to the server and therefore you don't need local data processing capabilities in the tool. That insight has changed. Anders did hint us before LINQ came out about that change of insight. LINQ does provide processing of data on a high abstraction level (4GL) on data (mainly on arrays and collections). MS has admitted that local dataprocessing DOES HAVE value.
>I know that. However the equivalent of VFP cursors are ADO.NET recordsets, on which LINQ runs fine. This will make post processing of data a lot easier.

First, VFP cursors are analogous to .NET DataTables - recordsets are a vanilla ADO entity. What surprises me is that you suggest that VFP-like post processing in .NET will come from running in-line DLINQ SQL against fetched data? In my view, what was strong about VFP in a post-processing capacity was its ability to use a myriad of navigational and record processing commands against data in a cursor or related cursors, and not just the post-fetch in-line SQL the got the data from one bigger cursor into a smaller subset cursor. You can filter data using SQL syntax against an ADO.Net DataTable right now - you don't need DLINQ for that. So, for the most powerful navigational data and record processing commands available from Foxpro/VFP, they are simply not provided by DLINQ.

>>If you are suggesting that LINQ to SQL is a nod to this Foxpro legacy, I think you are mistaken. In fact, in-line SQL in VFP was great for "quick and dirty" and this, unfortunately, is part of the Foxpro legacy too. The fact that you can do so many "quick and dirty" things in VFP (like adding properties "on the fly") is what gave VFP its somewhat undeserved bad reputation in many quarters.
>Hmmm, I doubt that. The only thing that might have contributed to that are the missuse of marcos.

Yes, the mis-use of macros is another to add to the list.

>>If LINQ to SQL floats your boat, then great. However, again, this feature is not IMHO going to keep your average .NET developer partying all night.
>No, it is about post processing of data, not getting the data directly from the server through LINQ.

My previous comments refer - post processing of data in VFP was greatly enhanced by X-Base navigational and record oriented commands, not just in-line SQL. Take those commands away from VFP and it would have been greatly inferior at processing data, post-fetch, irrespective of its in-line SQL capabilities. Moreover, the fact that you could use UDFs in Foxpro SQL was another use of Fox record processing commands that is obviously not available in DLINQ.