>My vote is to either return an empty string, or return an XML string that can execute with XMLTOCUROSOR() but it creates a cursor with one field called Error which is a memo field and contains the error (or more records for more than one error), so that if any non-empty string is returned, it is XML, always works with XMLTOCURSOR(), and when the cursor is created, you can check FIELD(1)=="ERROR" and if so, an error occured and all error info is in that table (more fields can exist in the table if needed, otherwise it would be a valid return.

That really won't work because MSSOAP will throw an exception that you have to handle first... You need to deal with that and parse the response from that before you can go on with the next thing. If you did throw a COM exception then there won't be any return value since the method call failed.


>Under no circumstances should an empty or invalid query result in a COM error which surfaces the VFP error handler, this would require full error handling enabled any time the XML Web service was called, rather than just simple code checking either the return string or the XML result (the cursor created), without having to set or modify any ON ERROR handler just to call a method.

Well, there's really no way around this because that's how the SOAP handler works and that's really the proper way to return error conditions from a SOAP method call whether it's a hard or soft failure.

On FoxCentral, an invalid msg id for example will cause a SOAP error to occur. Any SOAP client must be able to deal with SOAP error messages because there could be a number of them including connection issues.

Essentially what should be done is to have a wrapper around the SOAP calls that handle any errors and then allow you to retrieve that error. On foxcentral the client wrapper does something like this:

lcXML = THIS.oProxy.GetItems(ldLastOn,0,lnProvider,lcType)   
IF THIS.oProxy.lError
   MessageBox(THIS.oProxy.cErrormsg)
   RETURN .F.
ENDIF

The call to getitems handles the error in this case should there be one. This way you have a clean interfaec to *any* errors whether it's SOAP exceptions, connection problems or an application failure and you don't need a customer error handling/parsing scheme that'll be different for every method.