>>>If I was still working full time in vfp, sheling out for such fixes might make sense. But unless a new header type for .dbf local munching is introduced, which offers > 2GB files I think 64bit will not be a game changer for giving more speed via less disk usage. Biggest wory is that those new versions did not pass testing runs similar to vfp when new versions were introduced.
>>
>>2 GB limit doesn't matter so much. .DBF files already like to be flu in a few wind so best thing is move to SQL Server side.
>
>I totally agree for applications: since MS messed up SMB and oplocks, all user/customer written data should NOT be targeting .dbf.
>But ***I*** often had to do some basic data mining/grouping tasks: doing these in vfp on a WS is for me sometimes nicer than runing them in a SQL backend.
>And there that barrier sometimes has to be coded around with the data sets falling towards me ;-)

I agree using with the general sentiment here. Nowerdays DBFs should not be used over a network. Only when the database usage us very light and the application is very simple it might be an option. Installing SQL server on a server is also not always straightforward. In the past I wasted a lot of time with firewall issues, setting protocols and even installing SQL server itself. So DBFs are definately much easier from an installation POV.

OTOH, when DBFs are on the workstation itself, it still is a viable option. installing SQL server might be overkill in such cases. I got a few products like that and they are running DBFs because SQL server does not make sense there, Those are applications that run on thousands workstations as single user applications