"Access and FoxPro, being part of Microsoft Office, are examples of products that have integrated database engines that work well within their context but were never fully integrated into the Visual Studio development environment, as they weren’t considered general purpose data storage engines."

I wouldn't say this is wrong. VFP is so much more than just a general purpose database, its a development environment, its a database, its an IDE, it is so much but, these features are so tightly bound together, to separate its local storage capability out of the whole product was probably a bridge too far and, maybe the X-Base connontation was considered too negative for non-Fox users.

>Oh, was that why? I thought it was because the Fox community asked for VFP not to be included in dotNET because they didn't want to lose their data handling features ;-)

Well, that was the "spin" but I am not sure that MS ever considered what the user base actually thought/wanted. There are many developers who wanted VFP in .NET but that was never going to happen either. AFAIAC, they never wanted VFP in .NET/VS and that was that.

>I'm presupposing that performance is OK and that it integrates cleanly so you don't end up with gigantic code towers to replicate something you'd do in a few lines of code with an indexed cursor and a temporary table.

Its just like what would do with any piece of T-SQL and database/tables except that its "local" and it will interact easily with a "daddy" SQL server :)

Personally, I am getting messages all the time from VFP developers who are starting to look over to the dark side :) I don't think the fear is there anymore. What's wrong with learning a new language or using another type of data store. It doesn't make VFP any less useful, it just other tools in the tool box and that can't be a bad thing.

Best