>There are two things that separate VFP from VB. One is the language that is designed to handle data and the other is the fast data engine.

Yes, and if we created a VFP.NET than it would loose both of those separating features. Why? Well, VFP would be in no greater of a position to access data than VB at this point, because they will both run on the same runtime and both will be accessing data throuh ADO.NET. Nothing else.

>If Fuji can put COBOL in the CLR why can't MSFT put VFP in the CLR?

Microsoft CAN put VFP in the CLR, they could also add VFP to IE and make it a client side scripting engine. I think its a well known fact that they can do technically anything they want.

The problem is... why woudl they want to do that, and what benefit does it bring to the VFP developer? First of all, if they did go CLR with VFP, you would have to forget everything you know about VFP command and functions, because all of the real power in a .NET language is not in the language itself, the commands and functions are left up to the .NET framework to handle. Second, forget everything you know about the IDE, its gone, it has to use VS.NET's IDE. Now, what we're left with is a language that is VERY similar to VB that runs on the same runtime, is developed in the same IDE, that can access the same data, the same way.

So, as a VFP developer that wants to take advantage of CLR and VS.NET... LEARN VS.NET! It would be the same amount of work wether you're learning VFP.NET or VB.NET.