Jos,

>I have no idea if you are right or wrong David. I am not part of the .Net dev team :) ...

I'm not either, but I do know that .NET languages get most of their functionality from the .NET Framework which is supported by the Common Language Runtime (CLR). If a local cursor engine with data manipulation commands (other than ADO.NET) is not available in the .NET Framework then what everyone would want with a VFP.NET is not available yet.

I, for one, don't want a VFP.NET that uses ADO.NET as its only data access methodology.

>...But iac I dont think this is a technical issue. I think this is a business and political decision...

I think it's all three. It definitely IS a technical issue, since the capability is not there yet in the .NET Framework and any other solution I can think of involves crossing COM or conversion boundaries that would impact performance and still not give you the local DML and cursor.

In another message, Ken admitted that it's not technically impossible. I'm guessing that he means that the VFP capabilities would have to be put into the .NET framework first. And, he has stated that putting more VFP-like features into the .NET framework is the direction Microsoft is moving at the moment. Makes sense to me, although that does not mean that there will eventually be a VFP.NET -- just that it might be less of a technical challenge in the future than right now. Again, just my opinion and nothing else. :-)

>...In another post I have already made clear that I am not arguing for or against a VFP.Net. That is a tired and boring discussion. But thanks and keep up the good work on FoxTalk.

The technical issues underlying the tired and boring discussion are very interesting to me, and in my opinion, have been largely overlooked in those very passionate discussions of "I want VFP.NET".

Thanks for the comments about FoxTalk. :-)