Terry,

A "memory leak" covers a lot of possibilities.
In general it means that memory is always being 'consumed' by something or other and never being freed (returned to the OS for re-use).

While VFP itself has had some bugs in this regard, very few if any remain, as far as I can tell.
One that I've heard of that lingers is running lots (like more than a thousand?) SQL-Selects. That seems to cause a memory leak and the known remedy is to close all table periodically.

You can easily get a "memory leak" in your own code though. The most common way this happens is by having a "dangling object reference" in your code.
A "dangling object reference" is a memvar reference to some part of *another* object. Such a reference prevents that actual freeing of the referencED object, EVEN IF YOU EXPLICITLY ISSUE A RELEASE command! In such a case the actual object reference memvar does indeed disappear BUT the object itself remains in memory. A simple sample:

oX = CREATEOBJECT("MyForm")
RefPage2 = oX.Pgf.P2
    *
    *
   lots of code
RELEASE oX

The actual memvar reference "oX" will disappear, but the object "oX" will remain in storage because "RefPage2" holds a reference to an object within the oX object.
Now imagine repeating that code over and over again. Soon enough you'll have multiple extraneous copies of object "oX" residng in memory.

I *guess* that another way that a memory leak could happen is to create many cursors without ever closing them. These would all occupy memory and eventually you would overflow into SWAP memory.

cheers
>Thanks Einar
>
>Still not sure what "memory leak" is/entails/looks like! :-) Funny - I've been in IT since 1980 and not come across this concept till the UT.
>
>Terry
>
>
>>Terry,
>>It sounds like a clasic memory leak problem. Keep and eye on the memory usage in the task manager for that application.
>>
>>Einar