Hi Christopher,
The distance from the server is irrelevant--it's only the speed of the connection that's an issue. If I open a table with millions of records, or 5 records, I don't see much difference. It does matter, how wide and how many indices I have on the table.
Any SQL statement must first open the table, then run the query. When you say, "opening the entire table", that makes little sense. VFP opens the table by tranfering some information about the table--not by sending the entire file to the workstation.
However, if your SQL statement is not Rushmorizable, the whole table would have to be transferred, and that would be painful, I'm sure.

You should determine how long it takes to open the table: USE PatientList, and how that time differs from opening other tables.
Then determine how long it takes to run your query. Over our WAN I can get a small set of records in a few seconds from a several million record table, but that's with a rushmorizable expression and no index on DELETED().
Again, this is not to say that running VFP applications over a WAN is a good idea--generally it isn't, but it can work, if marginally.


>We have one of our sites using a VFP application connected to our W2K server through a T1 line; all the VFP tables are kept on that server. Of course, the farther away from the server, the longer the data takes to reach a client application. We have a very large table, patientlist.dbf. If we issue the command
>
>use patientlist.dbf
>
>from the remote site, it takes FOREVER to open on the client. We really only need to get one specific record at a time. When we've triend a SQL-SELECT statement to get the required record, the application opens up the WHOLE table on the remote (taking FOREVER) before it creates the cursor. How can we query the table for the record we need without opening the entire table?
>
>CM