When you call a function in other APP/EXE, the other APP/EXE usually remains in memory. Although, this way is not a reliable replacement for SET PROCEDURE, since sometimes it goes out from memory. I couldn't find a rule for this behavior. I think it's managed by the memory manager.

I'm not sure about VFP, but in 2.6 you won't have an error when you call a function in the other APP and this one is no longer in the memory. The call is just ignored. This is extremly tricky. What's even more weird: the APP goes out from memory if you delete or move the APP file on disk! Not really weird if we think a little... :)

Vlad

>In my environment where an EXE is calling another EXE, I have found the following problem.
>
>Usually, in the life cycle of the main EXE, it is responsible to fire a transaction in a sub EXE and returns back to itself in wait window for the next transaction. So, the sub EXE only lives for a fraction of a second, just the time it takes to process the transaction that has been received from the main EXE.
>
>In that kind of environment, I am able to BUILD a sub EXE at any time because it is not up and running in memory all the time.
>
>But, I have found that I can't BUILD my sub EXE anymore because I have a file access denied and here's why.
>
>I just added Network=CREATEOBJECT('Network') in the startup of the sub EXE. When the sub EXE receives a transactions, it processes it as usual and returns the control back to the main EXE. However, something remains in memory which avoid me to BUILD my sub EXE. If I remove the Network=CREATEOBJECT('Network'), everything works fine.
>
>I tried RELEASE Network and even putting .NULL. into Network before releasing it and this didn't change anything.
>
>Can someone tell me what is staying in memory and what should I do to clean it up?
>
>Thanks.