>Hi Jim,
>
>>In the second paragraph below, are you saying that VFP is taking into it's own hands what the OS should do for an application???
>
>Yes, that's why you get so different results for SYS(3500) performance measuring. You can verify this easily. Limit the amount of memory to a a few MB and perform a select on a table that is considerably bigger. Open a memory monitor and execute a partitally optimized query. You will see that VFP allocates memory until it reaches the specified limit. After that, the TMP files start to grow.
>
>Nowadays it often doesn't make sense, but it might have its merits. For example, you could have a fast system that can access several drives parallel, like SCSI. If you put the Windows swapping file on one drive and the temporary files on a different one, you can speed everything up.
>
>Until recently, VFP had no chance but doing the memory management itself. Assume you wanted to do a SELECT on a 1.5 GB DBF file a couple of years back with a system that has 128 MB of RAM and a local 4 GB drive where you won't create a swap file of 2 GB size just because VFP might need it.
>
>Christof

Christof;

Another technique that is used is to have CDX files on another server. It speeds up access but creates the issue of keeping the CDX files in sync with the dbf. There is always a price to pay regardless of the technique used. Sometimes a technique will work for a specific requirement. :)

Tom