We look at all this very much the same way. But I also notice the defense of dbfs pretty much can be summarized as 'maintenance' and 'legacy'. And that means developers who want to use VFP for new development (and I am still doing) need to know how to write n-tier apps and talk to real databases.

>IMHO dbfs do still have a place. I know it annoys some people ;-) but I always return to the Quickbooks example. Until 2006, Quickbooks "clung tenaciously" (sic) to a proprietary local file storage system as it became the dominant player in the small-medium business accounting space, before finally converting to the SQLAnywhere pseudo-C/S database. Large numbers of customers had trouble with the change. Intuit weathered the storm because it is so dominant. Assuming that FP developers aren't as dominant, it would be a serious risk to expose unwilling customers to such turmoil if they are happy with the status quo. Sure there must be some developers out there who simply refused to change away from dbfs, but there are also competent developers who understand their customers very well. If people wonder why so many "freeware" versions of expensive databases are out there, there is one reason. Whether people satisfied with local tables can be motivated to change is yet to be seen. ;-)
>
>I also note that Anders H has been saying for 2 years that NET needs to bring data handling closer to the language, using FP as an example. Perhaps some developers already knew the advantages of this approach which is why they remained with select mydbf rather than moving to "more modern" approaches like dataadaptors or ADO when exhorted to do so. ;-) FWIW, we converted almost entirely to C/S databases in 1995 (which was only possible because every customer has an IT department) but we still value indexable persistent cursors for local data munging that NET can't match to this day.
>
>As for the progress of Fox: in those early days truly it brought the ability to create slick apps right to peoples' door, at a time when businesses could achieve visible advantage merely from using "a computer." A written estimate printed with an inkjet and scaling fonts looked really professional compared to the prevalent dot-matrix or typed responses. The ability to process a month's invoices in minutes was a "wow" for people used to a protracted chug-a-lug in which the box might crash and wreck the whole batch. So a lot of checkbooks came out eagerly. Those were the golden days when people probably could drag a dbf onto a form and charge $$$$. But these days everybody has laser printers and proportional fonts and an invoicing system etc etc and if they're going to spend $$$ they want to see the extra value. Even moving to net or java or whatever won't magically create value for customers who need to choose whether to replace the flatbed truck or upgrade to a new software version
>that delivers... what exactly?
>There are also theories about customer opposition to change that seem contrary to the furious pace of change apparently required in IT to satisfy practitioners fascinated by "infinite complexity," bless their souls. But there are whole generations/nations out there who firmly believe that "if it ain't broke, don't fix it." When they discover that something they like is "broke" because somebody else decided to "fix" something that seems to have no impact on getting the invoices out on time... well, I'm not sure that some people have thought that one through carefully enough. I guess we'll see.