I think the standard thing to do for this is throw an exception. I used to do this in Fox too, where I raised a Fox error and let the result from that be carried back too...

I haven't tried this in a while either what exactly comes back - most of the services I use right now don't need to know why it failed, just that if failed <g>...

If an exception comes back you may have to look at the inner exception etc to the get the real deal... I think the main thing comes back as a SoapMethodException or something like that.

+++ Rick ---

>Is there a standard practice for returning error information to a consumer of a web service?
>
>A web method can return different data types, so it would seem that it would make sense for a web method to return a NULL value to indicate that an error occurred, allowing the client application to detect and handle the error. However, it would be nice if the client application had some way of retrieving some more meaningful and helpful error information from the web service. How is this normally handled? My first thought was to have a GetError() method of any web object class, so that if a method call returns a NULL value, a subsequent call to the GetError() method could allow the client application to determine what went wrong, and what information to give to the user.
>
>If this is a good approach, what is the preferred mechanism to preserve state between the return of the null "flag" and the subsequent call to the GetError() method?
>
>Thanks.