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.