>>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.

That exactly the approach I built with a sample code to query our Web Service. So, either in your case or from what I built, a customized error handler to handle those items should be implemented. As far as I understand, if I would call a method to FoxCentral with an invalid ID, this would result in a COM error to be thrown right away assuming I wouldn't use your client which includes the wrapper.

So, basically, does this mean that providers of Web Services usually include a sample code to deal with that instead of just letting the user to figure it out by themselves? This would then bring the issue of platforms and development environments where users would have to convert the sample code to fit their own platforms and development environments.

Because, for example, lets say we call a method which should return a logical. Assuming a validation takes place on the server, we have to return a validation string. The client would expect a logical but we need to return a validation message instead as the process can't be done. In this case, a simple approach to verify if the string is empty won't work as, at base level, we expect a logical. This is how I came up with the COMRETURNERROR approach combined with a client error handler, which is like you wrapper, to deal with that validation message.