Hi Christof,

>The background/foreground buffer affects the speed of the query when you run it a second time, not when you run it the first time. The real time that this query takes is what it needs the first time you execute it. However, when you decrease the foreground buffer beyond what VFP needs, you can artificially slow down this query, because VFP would start swapping to disk if though there's plenty of memory available. In other words, not how much memory you have affects the speed, but what you are willing to give VFP.

There are a few techniques that would clear the buffers made by the query.
You can restart your computer after each query, but of course this is one of the least attractive ones.

A strategy I use in testing is the following:
1. Open the tables on another workstation after you opened it on the testing machine and write some data (update or insert) to each of these tables.

2. Additionally, if 1 is not working properly, use SYS(1104) and SET REFRESH TO 1,1

suggestion 1 Would prevent the SMBs oplocking mechanism to allow large read buffers on the client machine (on OS level). See Q129202 and the platform SDK. The SET REFRESH and SYS(1104) might discard read buffers on the VFP level.

I've used this technique with much succes to test performance of queries and applications in real world situations.

Walter,