>>>Hi Michel here goes my opinion
>>>On scenario 2 / 4 I will use COMRETURNERROR since I whant to state that an exception has occurred e.g. validation failed or an error as occured the explanation message is what you put on the comreturnerror.
>>>On scenario 3 I will return an empty string since everything is OK but no data has match my criteria.
>>
>>Good for point 2 and 4.
>>
>>As for point 3, this will then force the client to implement the logic of verifying for an empty string before converting to a cursor. But, for that one, it is as good as the other approach. I was mostly looking for point 2 and 4. Thanks
>
>Michel about point 3 if the client don't implement the check for empty he will get an error when trying to do an XMLTOCURSOR in this case the error routine will enter in the game.

Well, as soon as you kick in a validation, he'll get an error anyway. As Rick mentioned last night, doing it with an overall logic solves it all. Unless you only have one method or a few which will never deals with validation, you're ok. But, in my case, I'll end up with at least 100 methods and most of them have validation. So, I have to rely on a minimum implementation on the client side. Such as the SOAP header handler requires for various purposes.