>>I just tried your code IN COM+ and ObjectB Returns an error to ObjectA Even in COM+, so i guess i was wrong, you and Craig were right. I guess My code was wrong in my tests.
>>
>>But we still have a problem with ComReturnError(), In your code, the error Method returns to the client without cleaning up the LOCAL Var loCom2 and VFP will not clean it up for you so how do we cleanup loCom2 by setting it no NULL from the error method ???
>>
>
>Hmmm... this might be an area where things are different in COM+. In my tests, when ComReturnError() was executed in the Object A (ComError1) Error method, then ComError2.exe disappeared from the Windows Task Manager Processes. I can only guess that loCom2 was considered out of scope at that point and released.
>
>In any case, I agree with the technique you presented earlier, where you set a flag and message in the error handler, thereby delaying the reporting of the error until you can clean up. You could use the same technique with ComReturnError. Instead of returning a text or XML error message, you could call ComReturnError() if you wanted to trigger the error handler in the client. At that point, it is just personal preference of whether you want to return a text error message or trigger the error handler. I think there is more flexibility with your method, as long as you are equipped to detect when an error occurs, which obviously you are.
>
>Good discussion and exercise for me, since I don't deal with COM everyday.

Yes we could guess the object is now out of scoop when the method is done. But i prefer making sure then guessing that VFP cleaned it up. There is an interesting article dangling object reference at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxtk99/html/FT99J8.asp You can see how easy it is to create lost references an C5 afterwords.