Hi Fred

You could do this...

Main.prg

Private var1

DO SHIPPING
RETURN

SHIPPING.PRG

*Var1 is visible as if it is public from main.prg down.
*if you create private var1 here it will result in 2 memory variables.
*now create other private vars here.
*They will disappear when this program ends.


That should avoid any public variables and make it easier to track the variables that come into existence.

I don't think there is any way for a piece of VFP code to differentiate between a global variable and a private variable declared in a calling routine.

Further, I think clear memory will release all variables, not just the ones defined in the current prg.

>Greg,
>
>The reason there are so many variables involved is because I am attempting to run part of a fairly complicated VFP-based accounting program (the part which ships orders, creates invoices, and updates inventory) from an external VFP application which allows you to schedule programs to be run automatically on what ever time schedule you set up.
>
>In order to execute the "shipping" program, I have to create the same environment as if it was being run from the accounting program itself and I am using startup procedures from the accounting program to create that environment. These procedures initiate global variables and arrays the shipping program expects.
>
>By using RELEASE ALL or CLEAR I was trying to clean up VFP memory before returning to the scheduling program and avoid the Too Many Variables error the next time my "shipping" program runs.
>
>My main question is why doesn't RELEASE ALL EXTENDED reset memory so that it can start over each time with out eventually getting a Too Many Variables error? Does CLEAR MEMORY get rid of something RELEASE ALL does not?