John,

>On really large data sets, I doubt it. SQL is pretty fast...

>If inheritance is the # 1 most over-inflated 1-up VFP has over others, the speed of the local DB engine may be the the #2 most over-inflated feature with respect to comparing VFP to other products...

Again it depends on the situation. SQL is a set oriented language (at least it is suposed to be as it is positioned as an implementation of the relational model) where as xBase languages are primarely record oriented (though SQL is supported (sometimes in a limited way)).

The differences between the two approaches are huge. Within the relational model there is no mechanism to browse trough the resultset (though there are limited ways within SQL) whereas xBase languages have a record pointer to point to the current record.

The differences between the two mechanisms become clear when using a hierarchy of tables linked to eachother with the SET RELATION command (thus suing the indexes efficiently) to get the data you want. On top of that you can filter tables within the hierarchy to provide a very powerfull way to reach the same goal as you try to do with JOINS in SQL. Difference here is that the Xbase solution of using a hierarchy is many times faster than using the SQL equivalent (yes i've tested this), and requires less memory (there is no query to be executed) to get the data you want, especially when the hierarchy involves lots of tables (thus many joins in SQL).

Another advantage of this solutions is that it's pretty a-synchronous. The relations are searched whenever you skip to another record and the records used in the whole hierarchy are only requested from the file when needed, especially when different tables are distributed on different sites over a WAN.

Of course when it comes to analyzing/transforming data out of few tables (comming from one site or connected with a high speed connection), SQL is many times faster than any xBase solution (MAX(), SUM(), AVG() clauses in combination with GROUP BY/HAVING clauses)

Another parameter is the Server capacity issue. I've seen too many cases where the server where SQL was running on was hopelessly underequiped (Small to medium large companies). The workstations often had a faster processor than the server (though this one mostly has more internal memory). In this cases a local database engine should provide far better performance because each workstation has it's own CPU and won't burden the server CPU when several workstation are executing fairly heaving SQL commands.

That's why I love VFP. It can use both of technologies even if one table comes from a SQL - server, the other is stored on the local network and the third is accessed through a WAN.

Walter,