>Here's the excerpt I was refering to. It's from VFUG April 1999 Newsletter.
>
>
>Queries against large tables creates a great deal of network traffic. For
>example, if there was a Contacts table with 50,000 records and you issued
>the statement:
>
>SELECT LNAME, FNAME FROM CONTACTS WHERE ZIPCODE="32216"
>
>and there are only 12 matching records, how many records do you think will
>be transmitted from your LAN server to your PC? The answer is: 50,000.
>Remember, all the processing on a VFP-only system is done by the client CPU,
>so all of the records have to be transmitted in order for the client machine
>to read and accept or reject them (I realize that Rushmore doesn't
>necessarily send the entire record, but play along). Again, even though you
>have a network server, that is not the same as a database server.
>
>By using client/server architecture, the server does the vast majority of
>the query processing. In the above example, the SQL server itself does the
>work; only the two fields for the 12 matching records are sent over the
>network to the client.
>
>LMK what you think. Thanks
>John

Do you mean that VFUG artcicle literally claims this? That would be a shame.
I hope, that these things are originated along the DELETED() tag lines. There was extensive discussion here, about the same time, and consensus (if taking that discussion optimistically) is that DELETED() tag may slow down some (usually non-practical queries) forcing whole index (not table) tag to be transferred to client. Again, it's applicable and may harm only in some narrow situations and can and must be avoided. This is question of narrow specific design approaches, but in general, VFP is blazingly fast.
I did not mention Rushmore here, assuming that you're well aware about it.