>Hi Bill,
>
>>This probably isn't a Rushmore problem after all.
>
>Exactly. What your query has to do is to read any record in table 1 and seek it in table 2. You are not limiting the result set and therefore Rushmore can't jump in. Eventually it might even be faster to avoid Rushmore at all here and use a pure Xbase solution. In other words, open both tables, set a relation from table 1 into table 2 and then do a SCAN FOR EOF("Table2") to find all records in table 1 that have no corresponding record in table 2.
>
>The speed issue you are seeing is caused by caching. After you executed the query the first time, VFP read everything into the cache. Running the same query a second time fetches all information from memory and not from the hard disk. By switching to a different application, you tell VFP to switch to using the background buffer and discard cached information that do not fit into it. This is controlled by the SYS(3050) function.
>
>Christof

Hi Christof,

This is new to me. I want to make sure I understand this. I checked out sys(3050) and understand that part.

If I understand you right, the TRUE time that my query takes is the first time I run it. Switching to a different application (while VFP is waiting at the command window) switches VFP to background buffer and throws out the foreground information, so when I switch back to VFP (doing absolutely nothing in the other application) and run the query again, there is nothing in foreground buffer. I'm guessing that it was moved to background buffer when I switched to the other app and thrown out because there was too much, so when I switched back to VFP there wasn't enough to run the query off of.

I just test that idea, by equalizing both foreground and background buffer, and sure enough it ran the query at the same speed each time. It was 3 times as long (because the buffer was so much smaller) but it was the same each time.

So the speed of my query is a function of the design?