>>we're testing thin client using Hydra beta and everything run fine until our VFP app does a SELECT SQL statement (which only happens in one place, I'm using the boring old methods elsewhere). When the statement begins and the progress bar appears, Performance Monitor shows that all of the available memory (256meg!) is being used by VFP... everything else _and VFP_ come to a screeching halt...
>>
>>when I abort the SELECT statement, VFP holds on to the memory. It doesn't release it until I QUIT.
>>
>>Two questions...
>>1) How to make VFP use less memory (sys(3050) didn't help)
>>2) How to make VFP release the memory when it's finished
>>
>>LM
>Larry,
>Don't know what "thin client" and "Hydra" are. Is it really related with that ? Does "thin client" mean BNC network ? Could you be forcing SQL to select table1.recco()*table2.recco()*table3.recco() and so on ?
>Cetin

SELECT statement is only one table ...

SELECT * FROM TAPEFILE WHERE COUNTY='CL'

Tables are optimized so the problem is not the code... it's the internal memory usage of VFP.

A paragraph from TechNet CD:

If VFP still needs more memory after compression, it requests another memory block from theoperatoint system.

The requested block size is large, so VFP doesn't hagve to send requests to the operating system often.

Aong the same lines, VFP doesn't release memory from the pool until the operating system requests it back. This is done because memory requested by VFP is assumed to be needed again. It require a lot of time to request memory from the operating system, so