I'll have to check out Vista. But I'm not really ready for that yet.

I may not fully understand your question here but typical data usage is to grab only exactly what you need when you need it.

Yes, but my usage isn't typical.

I grimace every time I here someone compare VFP to Dot.NET because to me they are totally different animals. I don't view them as 2 application development environments, I view one as a set of programing languages and the other as a database language. For me the correct comparison for VFP is TSQL. And frankly I find TSQL to be rather lacking.

I do develop apps in VFP and for that Dot.NET is a great replacement. There is a lot to love about .NET

But as I said, my usage is not typical. The average life of a datafile for me is 3 days. I deal with up to 20 new datafiles every day. That's just not typical. Each one is unique, each one has it's own set of problems. They can be small or they can be large. They can be in decent shape or they can come from Outlook. <g>

And yes once I have defined the problems that need to be addressed with a data file I filter it down to just what I need. But I have to first define the problems. And paged browsing of datafiles is too limiting and restricting for that purpose. It's like the difference between reading a magazine and viewing data on line. Thumbing through a web site just isn't the same as thumbing through a magazine.

I was looking at the datagridview last night and think I may have found one solution. I may be able to override one of the types that it can be boundto to provide a buffered data set.

Thanks for your input, hopefully the above better explains my situation.

John

>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