>>>>>>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!??
>>
>>I doubt that's happening. Seems more likely that both would simply grab the next record indicated in the bitmap.
>
>That may well be, but that would put the large chunks theory in question.
>Then, considering that even the OS and even HD controllers can now do "ordered seeks" to optimize disk response, it only makes sense to me that Rushmore did it first < s >.
>
>>
>>>
>>>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.
>>
>>The only real difference I can see here would be one-large-compiled SQL versus lots of interpreted and re-interpreted lines of xbase code.
>
>Which should be next to negligible with a 3GHZ processor.

Nope. It will add up if you scan a million rows, versus sql-select a million rows.

>
>>
>>>
>>>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?
>>
>>Fragmentation would be equal if you ran a SCAN FOR and a SELECT WHERE.
>
>Agreed. BUT... the contention being that one does large chunks and the other single records, it would seem to me that fragmentation *should* play a role for the large chunk player, in it's determination of how big a chunk to bring over.

To the best of my knowledge VFP does single records. At the lowest level its navigating to a byte offset in the file. Caching and Rushmore only make it seem like it's doing multiple records at once.

>
>cheers
>
>>
>>>
>>>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.
>>
>>That would be my guess too.