John,

>A cursor IS a dbf.

From a technical point, a DBF is different from a cursor in a quite a few aspects. So your statement is incorrect.

>That said, sql operates well on ADO - and the back-end of course. And for the record, I can have just as data driven app using data from the back-end as I can with DBF's.

You can´t do this in .NET or VB/ADO because you cannot process the SQL commands locally. I don´t know why you think ADO itself processes SQL commands. IT DOES NOT. It passes the SQL command to the backend for processing there, Not using the workstations available resources, but in stead stressing both the network and the backend server.

In data driven VFP applications where a lot of meta data is loaded onto the workstation (In cursors, whether it comes from SQL server, a DBF on the disk or a dbf stored within the executable) you can do complex SQL commands on this local data. A good example is that the for example the security rules, stored in a VFP cursor which is used to determine accessrights troughout the whole applications (A hierarchical security model simular to accessrights on folders in Windows) can easily be applied to the results comming from a SQL server to filter out the records, or mark as readonly to which the user does not have access to.

If you are ever to implement this in a .NET situation then you either have load the security info on the SQL server and on the client (Because the security model is also used to grant access on objects, and functionality, which need very high performance and therefore need to be on the client) and process the SQL enterily on the SQL server. Appart from that a hierarchical structure (which the security model is) does not mix well with relational data, it raises all kinds of practical problem, of which performance is a major one, synchronisation and complexity another. ADO and ADO.NET cannot process SQL (or other complex DML) locally on their resultset, You can do on VFP cursors.

This, my friend, gives VFP a tremendous advantage in creating data driven applications, Simply VFP has the tools to quickly process data locally and does not have to rely on external backends.

VB.NET has a long way to go before it can beat the local database advantage of VFP, no matter how you put it. This has an inmediate effect on how easily you can create data driven aplications.

John, you obviously have lots to learn before you see the light. It would suit you to learn beyond your "databases for dummies" and "How to hide that I know nothing I´m talking about"
knowledge. You clearly fail to see the difference between a database centric tool and a general purpose tool.

>Your argument is absurd...

Depends on your definition of absurd :)

Walter,