Claude,

Yes, I know VFP to .NET Interop works very well. I have used it on several projects and intend to use it on many more. It's one of the best ways to leverage legacy code when the project requirements specify some form of .NET (Web or Winforms).

My point is that we CAN do that now. You just don't have local data manipulation commands against a local VFP-like cursor inside .NET and that's why there is no VFP.NET yet. If there were already a VFP.NET that did not have local DML commands against a local cursor and instead used COM Interop (as both of us have done), it would not be VFP in .NET.

>Despite some of the propaganda going around, VFP to .NET interop works very well and, *IMHO*, I would not say it's inefficent to any great degree. All you have to do is create a few VFP mtdlls, properly call them from ASP.net, and run some performance/scalability tests to see that this is true. Also see http://www.activevfp.com/avfpdemo2/default.aspx for an example...
>
>>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.