You welcome Bonnie, I just point it out cause in my opinion when something wrong happens you should always throw an exception instead of returning codes that you need to check on the other side.

>>Bill the are sent as a soap fault in the soap envelop, that will trigger a soap exception on the soap client that called the web service, you can then see the soapexception.message, this will have the equivalent to the exception.ToString, so you may want to do some processing before showing the message to the user.
>
>Hmmm ... ok. We're not utilizing that. We simply send a message back through our Web Service instead. There may some reason why we decided not to do it that I either don't know about or don't remember (we architected this thing a long time ago) ... or maybe it wasn't available way back when or we didn't know about it.
>
>Thanks for pointing it out. =0)
>
>~~Bonnie
>
>
>
>
>>
>>>Hi Bonnie,
>>>
>>>I would like to hear the answer to this. I believe that Exception objects are not serializable, so I don't see how they could be passed over the wire to another machine.
>>>
>>>Bill
>>>
>>>>
>>>>Well, I guess I'll have to test that. It doesn't seem logical to me that that would work. The exception would be raised on a totally different machine than the one that the UI is running on. The exception would have to be passed over the "internet". I just don't see how that would work.
>>>>
>>>>If I get some time today to test it, I will.
>>>>
>>>>~~Bonnie
>>>>
>>>>
>>>>
>>>>
>>>>>>>Bonnie and why don't you raise an exception also in the web server that will be send to UI?
>>>>>>>Any special reason?
>>>>>>
>>>>>>You can pass an exception over the wire through a Web Service? Maybe you know something I don't, but I don't think you can do that.
>>>>>>
>>>>>>~~Bonnie
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>You just raise the exception in the web service and that will raise the exception on the client that is calling that web service. I'm I missing something?