>Here is an example of what kind of problem you could get into using ComReturnError()
>
>
>DEFINE CLASS MyClass As Session OlePublic
> Function SaveMyWork( oRs1, ors2 )
>
> LOCAL loContext
>
> This.Rs1 = oRs1
> This.Rs2 = oRs2
>
> *-- Create your object context here
>
> lnResult1 = This.SaveRs( oRs1 )
>
> x = y
>
> *-- At this point the control is given back to the client
> *-- The SetAbort() is not called, SetComplete() is the default
> *-- So the changes to the database will be committed even if oRs2 was not saved
> *-- Even Worst is i stored the 2 RecordSets in This.Rs1 And This.Rs2
> *-- and my GC Method is not called so i will for sure get a C5 at some later time when running this method again.
>
> lnResult2 = This.SaveRs( oRs2 )
>
>
> IF lnResult1 = 0 AND lnResult2 = 0
> *-- Call setComplete()
> ELSE
> *-- Call SetAbort()
> ENDIF
>
> ENDFUNC
>
> **-- Some more functions here including a error function with ComReturnError()
>
>ENDDEFINE
>
>
>As you can see, ComreturnError() is the problem here, as you say we should keep an open mind, and i don't say there is no use for ComReturnError(), i just say it is very dangerous to use it without understanding it fully.
>
Although I haven't worked with COM+ on a production environment (still running NT around here), my approach is to issue SetAbort() in the error function before COMRETURNERROR(). I've never gotten a C5 because of this.
In your situation, what happens if your error-communication mechanism fails? My guess is if the component keeps running, the client doesn't know of the exception and it keeps on with further processing, which could be risky.