>Sys(1016) is not supposed to be very reliable, but I've found it to be a good indicator for memory leaks
>inside of VFP.
>
>You have a couple of issues to deal with though. The DDE subsystem might be the problem, especially if
>you're seeing the wide swings. Also SQL connections can effect memory usage based on how long after a query
>connections are held.
>
>OTOH, VFP tends to consume memory whenever it can then not release it unless the system is totally swamped.
>What is the behavior you're seeing? It might be that this is VFP's intended behavior...
>
>There were a number of memory leaks in the original release of VFP 5.0 that have been fixed in 5.0a BTW.
>I personally had major problems with resizing arrays in one of my server apps that luckily got fixed
>with the updated version.
>
>+++ Rick ---

I've been able to eliminate DDE as the culprit. As well , I've been able to eliminate the memory loss reported by SYS(1016). It appears that an SQL SELECT statement (with an array as the destination) was the culprit (despite expicitely releasing the array).

However, available memory (as reported by System Monitor) is still going down. I ran approximately 11,000 transactions through in a seven hour period. Allocated memory increased by close to 2MB and free memory decreased by about 800K. All I'm doing is a couple of Seeks and a couple of Replaces. I HAVE noticed that not setting the Index Tag in the SEEK statement seems to improve efficiency.

EG
if SEEK(Expression,DBF,IndexTag) Less efficient
if SEEK(Expression,DBF) More efficient .. of course the index must be preset.

Is anyone aware of a better version of the System Monitor Application ?