Thanks Erik,

That’s the best answer I've seen and what I suspected all along. It's not that it can't be done its a simple issue of resource investment. It would not surprise me to see some vendor make a set of .NET classes available that provides some basic ISAM functionality. Once you’re spoiled with VFP’s data crunching capabilities, performing similar tasks with only the UDA model is like a bad joke.


>The .NET data solution is ADO.NET. To add special VFP functionality to the CLR would be bastardizing the universal data adccess model currently implemented in .NET. VFP is both a development language and a database system. .NET languages are just languages, not databases. In short, the VFP philosophy and and the .NET philosophy are simply not easily compatible.
>
>The VFP team has stated that it's not practical resource-wise to to develop a VFP that can run both managed or unmanaged code, so the decision to make VFP a .NET language would be a decision to kill all backwards compatibility: native data, VFP's string handling, memory management, inheritance model, VFP forms, controls etc. What you'd end up with is VB.NET with just a few syntax changes.