>I am absolutely sure that VFP8.0 will be VFP.Net. I am sure that Microsoft will release a strong database .Net tools.

I've never quite understood this mindset. Yes, .NET can't mung data the same way VFP can on the client side, but, are you suggesting that the VFP cursor engine be completely rewritten for the CLR? Or are you suggesting that the existing cursor engine work with the CLR?

If its the first one, I highly doubt you'll find many developers willing to risk going back to a version 1.0 product (a complete rewrite) for what advantages? Keep in mind that if the VFP cursor engine is rewritten for .NET it woudn't look like ADO.NET at all, or even use the same objects, making VFP.NET controls completely uninteroperable with the rest of .NET (and that interoperablility is, of course, the only reason why I would even entertain VFP.NET for a second).

If if latter, this already exists with COM. If anything, the best way to fix this would be to pump up the OleDB support, including language features avialable from Stored Procedures through the OleDB providor.

I'd like to understand your point of view, but from what I can see, moving VFP into the .NET world would be sudden death for the product, as opposed to the current situation where it has its own team and its own community that knows VFP can handle anything thrown in its direction.

So I guess my question is, what would VFP developers and end users of VFP applications benefit by VFP becoming apart of the .NET Framework (CLR, VS.NET, ect.)