Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
IE -> Backend via ADO
Message
General information
Forum:
ASP.NET
Category:
ADO.NET
Miscellaneous
Thread ID:
00881202
Message ID:
00882284
Views:
19
Hi Rick,

I think I'm getting confused (in fact I know it!)

OK - so the client side is sending back a well-formed bit of XML in the SOAP body which complies (AFAICS) with the WSDL. So SOAP (per se) on the client and server side of the webservice shouldn't have a problem? Are you saying the problem is in the 'de-serializing' process in .NET in converting this to an XMLDataDocument instance ? If so does that mean that a .NET based consumer of the same WS would also fail in passing a XMLDataDocument?

I noticed that, as you mentioned, there's no problem using a DataSet type as the parameter - even if the XML relates to a XMLDataDocument. (This doesn't make much sense back at the .NET Method but at least it gets into the method code without error)

IAC, as you say it's easy enough to work around but I still haven't found any concrete examples on the cleanest way of updating the underlying database from the XMLDataDocument. Maybe I *should* use a Dataset on the client - at least it carries it's own key/restraint info around with it so there'd be less work to do on the server when it comes back. But I'd have to have script in IE to keep the Diffgram coherent. Arrgh...

Regards,
Viv



>>
I've been experimenting using XMLDataDocument as the parameter type. Oddly this won't get through the SOAP layer when passing it back to the .NET web service. If the type is specified as XMLElement it works fine. The only difference in the schemas generated is that the XMLDataDocument is mixed complex type. AFAIK this just means that the content *can* be mixed - not that it has to be. Don't know why this throws things. I'm using the webservices.htc and guessing the problem may lie there...
>>

>
I don't think that's it. The SOAP parser knows about a few complex types like DataSet and XmlElement and performs custom actions on it. XmlDataDocument (or XmlDocument for that matter) aren't. This really shouldn't be a big deal from your end though since you can just pass the document element back and then on the other end simply reload the XmlDataDocument with this Xml... One thing that is nice that a lot of Soap Parsers can deal with Xml Elements directly so this is not just a .Net thing unlike soe of the other complex types like DataSet.
>
Previous
Reply
Map
View

Click here to load this message in the networking platform