>Just curious - is the VFP data being used by other applications?

It is, and I have a ton of other utilities written in VFP, the VFP for this will actually will be running on a different machine.

I am massaging and sorting entire tables and some of the data files are quite large, which .NET does not deal with in a reasonable fashion. I would have to do the work on the SQL back end.

They are also very transient tables, the average life of a table is about 3 days. Many of these tables also require varying amount of manual cleanup and I find the command prompt in VFP to be far more efficient than using SQL server.

So for now I plan to keep them in VFP. I have written a vitual List<> object that allows me to use VFP data in .NET and lets VFP handle the data cache. That way I can view a large VFP data file in .NET without using up too much memory.


>>If not my first inclination would have been to move it to a SQL backend such as MSSQL Express that integrates easily (and more efficiently) into .NET. But maybe I'm currently biased after finding Linq to SQL such a pleasure - at least for the usual simple data handling that's often required.
>
>Oh, and before anyone jumps on me, I'm not comparing Linq-to-SQL to native VFP data handling - just to DataAdaptors/Datasets etc. in .NET...

Heck, they can flame me. I'm finding Linq-to-SQL to be far more powerful than VFP for LOB app type coding. I can easily represent very complex data structures in code way easier than I could in VFP. Linq is actually an awesome technology and so far I am very impressed with it. Hook it together with WPF and it sometimes blows my mind what I can do with the two technologies and a few lines of code. Learning them was a nightmare at points, but now that I have... WOW. (I didn't feel the same way about DataAdaptors/Datasets.)

But a good part of what I do requires me to get up close and personal with the data files. And for that VFP is still by far the best language out there.