I haven't tried, but would it be the same behavior if instead of first poLog = NULL you'll use
poLog = createobject('empty')

>Peter,
>
>I don't know if this behavior has been identified as a bug or not, but I have made it a practice for several years to call a cleanup method for each object before the destroy fires. I also see that version 5.0 of webconnect has a dispose method in all the classes that gets called before releasing the object. I saw a post by rick where he said that VFP sometimes doesn't clean up very well and that is why he did that.
>
>>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?