>>Isn't it true that when a workstation looks at data in a FoxPro table on a VFP form, that the entire table comes down to the workstation physically, perhaps as a temp file that is recognized as the table? And, isn't it true that this causes the LAN's bandwidth to be high if the tables are large?

Cecil, there used to be quite good published tests of this, but long gone...

If you perform an optimized VFP query, the index is brought followed by the resultset records. If you perform unoptimized queries, all records will be brought across.

If you are performing heavy manipulation, bringing across a large resultset is not only feasible in VFP, it can create efficiencies, since neither the server nor the network is further burdened.

In general and in most development environments, doing things at the server is more efficient. One reason is that most contemporary development environments keep local resultsets in memory, and not always in a very efficient format. An unexpectedly large resultset can bring a machine to its knees.

If I recall correctly, a properly optimized VFP table consumes between 2 X and 4 X as much bandwidth as SQL Server when performing predictable queries for a data app. This was perfectly acceptable in my customers in the 1990s but as business networks became busier and servers stronger, it makes much better sense to perform simple queries against a backend. This is more true today with stronger machines and free versions of many databases. However, we still use VFP tables for local static lookups, depositing the tables on local machines to reduce burden on the server and network and to allow easy disconnected functionality. We also perform heavy processing locally, since as of August 2010 there still was an advantage to doing that.

HTH.