John,

>>I still think VFP Rocks and I am going to miss it sorely as it fades into oblivion. But then for most of what I do (data file cleanup, data/field standardization and preparation for mailing) I still have not found a good alternative to VFP. I have major utilities and applications that I have written in VFP for this type of work, but I still spend a good deal of my time at the command prompt tweaking things in the data files to get them just right. Doing the work with just SQL would be a pain and last I looked I couldn't even find the command prompt in Access.<g> I may end up having to go back to dBase.

Dot net does not really have a database but plays well with most. While it works with VFP data it isn't your best choice. If you want a stand alone database other than SQL server I would still recommend VistaDB. It is tightly integrated with Dot Net, is typed, and gives you integrated access to your data inside of dot net IDE.

>
>This is a bit down the road for me... but I've been thinking a bit about my VFP apps ever since I wrote this. VFP still makes the most sense to me for the custom DP work, and also for most of my custom cleanup utility code. Although I could leave my DP front ends in VFP, I would love to be able to move them over to .Net
>
>Just one problem that I can see... I need to be able to browse large datasets and I have a feeling that .Net is going to balk at me loading a 1 or 2 gig dataset. I DO NOT WANT TO USE PAGED BROWSING! I have one rather clunky solution of using a VFP form in my dot net app, but it has a lot of draw backs in it's implementation.
>
>Anyone have any experience with this or any solutions other than paging for it?
>
>Or is .Net already doing this and I just don't know about it?

I may not fully understand your question here but typical data usage is to grab only exactly what you need when you need it. loading in large datasets is not the best solution. That said, once again dot net isn't the issue here. The issue would be your underlying database technology. If you are using 1 or 2 gig data chunks then I would still think a real database server like SQL would be your best bet.

Tim