Jos,

>.Net is 3 years old, I believe, and only now are MS building in "VFP like data features" into .Net. Why now? You had VFP all along. The bottom line is that for whatever reasons unknown to us MS have decided that they prefer to add VFP like features into a language that does not have it rather than port the language that already does.

Think about it from a technical point of view. Here's the way I see it: If you wanted to put a local cursor engine into .NET that works like VFP, how would you go about that?

Someone might argue that it would be easy -- just wrap up the VFP engine into a COM DLL and wrap that up in a .NET package. Heck, we can do that right now, even using Calvin's old session example of "Your first COM object" that has DoCmd and Eval methods. The problem there is how to get the cursor that you generate "into" .NET so it can be used -- it would have to somehow travel over the COM barrier, perhaps as XML representation of a .NET DataSet. Heck, we can do that now by writing a COM component and using it inside .NET.

The problem with this is that it would not be Managed Code and would involve COM Interop and conversions from one form to another and would therefore be less efficient and slower, and you would still just be working on the .NET side with a DataSet.

Someone might argue that .NET already has enough IO classes to hack together a local cursor engine using low-level file IO. Right. That should be pretty easy. :-)

No, if you want a cursor engine in .NET that is Managed Code for speed and that has the same data manipulation commands as VFP available to the .NET languages, then it has to be written as part of the .NET Framework, right? That's a pretty big undertaking in my mind, and obviously was not high on the list of priorities for the first few versions of .NET. Maybe something like that is now being considered for upcoming versions, to be integrated into the .NET framework and therefore exposed to all .NET languages.

I don't have any inside information at all, so this is all speculation on my part. Repeat: I don't have any inside information, so don't read anything extra into my comments: It would not surprise me at all to hear at some point that members of the VFP development team were/are/will be working on a local cursor engine in conjunction with the .NET teams.

The main reason there could not be a VFP.NET, in my opinion, is that the .NET Framework did not have (and still does not have) the functionality described above to allow VFP.NET code to run in a managed environment and still have access to local cursors as we know them. Once that capability is there (if it ever is) some enterprising person(s) could write their own language based on xBase and make use of the local cursor capabilities in .NET, but not before it is natively supported by the .NET framework.

Just my opinion. Now, where am I wrong from a technical point of view? (I may be wrong, so convince me otherwise with technical arguments.)