That implies I'll have to revise the construct of the code. It is a 'job processor' that checks all kinds of potentially troublesome conditions underway. One of the most troublesome problems is an error in the log routine, which is even called by the ON ERROR command. My solution was to use RETURN TO MASTER or RETURN TO MAIN_JOB in that ultimate case, in order to prevent further errors (including possible eternal loops) in the regular RETURN and CLEANUP code.

Oh well, I'll work out some solution, I hope. Thanx for the confirmation of my hunches.

>We ran into this with our business objects in VFE ten years ago and decided it was best practice for any object instantiated within the scope of the business object to call its destroy() and then set its object reference to null before calling the destroy() of the containing object.
>
>This seems to have taken care of the issue for us.
>
>
>
>>Here's the overall structure of a program:
>>
>>

PROC main_job
>>private poLog
>>poLog = NULL
>>main_job2()
>>poLog = NULL                     && <== here the Destroy() fires again
>>RETURN
>>
>>PROC main_job2
>>     poLog = someobject()
>>     RETURN                     && <== here the Destroy() fires first
>>

>>
>>The object has cleanup code in its Destroy(). I'd expect the Destroy() to fire where I set poLog to NULL again. However, it also appears to fire on the RETURN of main_job2. Why?
>>
>>But there's a far more serious problem. Within the second Destroy() the internal memory space of VFP gets screwed up totally, ruining certain variables. This happens on the line of code where variables are declared LOCAL (in the Destroy Event).
>>
>>Anyone here familiar with this quirck/bug? Is it my misunderstanding of some concept?