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 ) && Save an ADO Recordset with some data 
   
    x = y && This causes an error and causes the program to stop executing because the error method call ComReturnError()

    *-- 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 ) && Save an ADO Recordset with some data 


   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.


>I would have an open mind here. Why would MS put this function in if it's causing such great harm?? In our circumstances ComReturnError has helped a great deal..
>>There is no difference between calling a VFP MTDLL from a VFP Client, VB Client or an ASP Page or any client, The MTDLL simply doesnt care and doesnt know what is calling it.
>>
>>COM+ VFP MTDLL are also Stateless, Meaning after you call SetComplete() or SetAbort() the object is removed from memory on the server and return to it's original state.
>>
>>So, the example i gave is valid for both Web or VFP Clients.
>>
>>
>>>Web apps are different beasts.. We've found the best and simplest way to keep web com servers up and running smoothly is ComReturnError, but, I will take your advice under consideration and check out what you've said here. This probably doesn't apply to a regular Com+ application which is what you're doing. Remember, web apps are stateless...
>>>>NO!!! NEVER Use ComReturnError(), If you use it, you cannot predict where your code is currently doing and your GC will NOT be executed, causing very impredictable results and C5. Use a smart error handling instead, something like this:
>>>>

>>>>DEFINE CLASS MyClass As Session
>>>>
>>>>  ErrorText = ""
>>>>  ErrorOccured = .F.
>>>>  PROTECTED ErrorText, ErrorOccured
>>>>
>>>>  Function SomeFunction( cPar )
>>>>   LOCAL lcResult
>>>>
>>>>   *-- Create Your MTS Object context Here
>>>>
>>>>   *-- Do some processing to build lcResult
>>>>   lcResult= GetSomeXmlString()
>>>>   IF This.ErrorOccured
>>>>      lcResult = This.ErrorText
>>>>   ENDIF
>>>>
>>>>   *-- Call SetComplete() Or SetAbort() Here
>>>>
>>>>   RETURN lcResult
>>>>
>>>>  ENDFUNC
>>>>
>>>>   PROTECTED FUNCTION Error( p1,p2,p3 )
>>>>       This.ErrorOccured = .T.
>>>>       This.ErrorText = GetXmlErrorString(p1,p2,p3)
>>>>   ENDFUNC
>>>>
>>>>ENDDEFINE
>>>>

>>>>>However, for a stateless COM application like a web app (vfp mtdll), ALWAYS use ComReturnError. This is a good rule-of-thumb for web apps.
>>>>>>In addition to my previous reply, i just look at your code and remembered of another rule you should follow:
>>>>>>
>>>>>>- NEVER use ComReturnError() Using it will cause your component to stop executing and return the control to the client, again bypassing any Garbage collection method you may have. Since you never know where an error occurs in the code, it would also be impossible to predict the effect of stopping code execution.