>>>Going over the network always presents concerns when doing SCAN-ENDSCANs on a table. All the data has to move over the wire to the local pc to determine if it is in the FOR condition.
>
>>Some people think if you USE a table it's all transferred, but that's wrong. If the FOR condition is Rushmore optimized, the data is also not transferred.
>
>Yes, partially. Rushmore uses indexes to select which records participate in the SCAN, but only for those portions of the FOR clause that can be optimized. If a single SELECT-SQL is performed, then the table is moved in a single "chunk" rather than many small record size "chunks" across the wire. Remember also that Rushmore works in both cases -- my experience is that a single call is faster than lots of little calls to a table for records.

Moved in a single chunk rather than many small record-sized chunks?

First, the idea of "record sized chunks" doesn't seem right to me. Surely *both* Rushmores are smart enough to recognize adjacent records and ensure they are gotten at the same time!??

Then I wonder at the difference between "single chunk" rather than "many small record sized chunks". I assume they'd both amount to the same number of bytes transmitted. Just seems to me that many small chunks could be more network-friendly than a single large chunk. And given HD-level read caching and server OS caching and workstation OS caching and VFP buffering it seems there should be little difference between the two.

Finally, I wonder how fragmentation affects the whole mechanism. Vitrually evry single table in an actively used application will have fragmentation. I wonder if that impacts the chunking algorithm?

My guess on the original problem stated here was that records being read / updated are under lock and the application is quietly waiting for unlocking so it can proceed.

Just some thoughts.