>>IMHO dbfs do still have a place. I know it annoys some people ;-)
>>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. ;-)
but I always return to the Quickbooks example. Until 2006,
>>Those were the golden days when people probably could drag a dbf onto a form and charge $$$$.

>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.

I personally start develop using dbf and model first in xbase using set relation, browse and 5 most important fields of each table. For me this gives me a huge head start against those using rose, object brokers or documentation. IN the last modeling phase the 5 fields might wander dummyforms to get a better feeling for the app. Then I switch over to cursor adapter using the base tables and create at least a 2-tier solution with my code at least seperated into special objects - sometimes there is no need for a sophisticated layered business tier, but those objects can be reused by or turned into a biz layer on a moments notice. Events in data and GUI layers only call my object methods. BAckend choice totally by the customer from MsSQL, DB2 and oracle or dbf. A purely techno/cost driven decision I don't invole myself heavily in and sometimes allow dbf by "force of sarcasm" only in at least TS/Citrix setups - which I see as a valid alternative to C/S backends for the user sizes kept on LAN a few years ago.

The speed gained I verified recently when building a GUI for several bigiron import tables using 1 and 2 byte chars as small- and tinyints (as some tables had surpassed 3.5 GB level - having forced columns into memo fields and all non-normalized data into special search fields in the also large cdx. Here I thought it would be great to use the cursoradapter's CursorSchema and the SelectCMD to get me "human-readable" fields all type I in the small subsets. Worked without a glitch, but the turnaround time on some schema changes reflecting outside change was markedly slower, even with having semi-automatic ways to fill the relevant properties of the cursoradapter.