Rick,

Well, it's nice to know that wwXML will handle converting the DataSet to a cursor ... I wasn't aware of that (I guess I'll have to try it out ...)

>Frankly if you do round tripping with DataSets, using anything but .NET on both ends is not worth the effort. You can do this but it would basically involve reverse engineering how data set updates work, which is not worth it, IMHO.<

I guess I don't totally agree with this ... If you're using a SQLServer back-end, and if you'd like to limit all your data access through Stored Procedures, I don't see how you can easily leverage how the DataSet updates work anyway ... unless I'm missing something (easy to miss stuff ... figuring out how to do things the .NET way can get pretty frustrating <g>) ... seems like you'd still have to build your SP parameters manually.

~~Bonnie



>Uhm, no not exactly. It returns the object in XML representation, which is just the same as DataSet.GetXML() (or the updategram version thereof). The difference is that it's not a string, but an internal schema'd XML document.
>
>You get a nodelist if you use the SOAP toolkit. Nodelists are difficult to work with because it doesn't give you a top level node that gets you the whole document, rather you have to walk the list and parse yourself or alternately you can provide a schema to let the SOAP toolkit know what's coming. Both approaches are braindead.
>
>(later)
>Ok, I looked at this again just now, and you can get the data out easily enough I suppose:
>
>

>o = CREATEOBJECT("MSSOAP.SoapClient")
>o.mssoapinit("http://westwindserver/codeservice/codewebservice.asmx?wsdl")
>loResult = o.GetAuthorData("")
>
>loDom = loResult.item(0).parentNode
>lcXml = loDom.Xml
>

>
>But XMLTOCURSOR doesn't deal with the with the recordset. I can use wwXML for this though:
>

>CREATE CURSOR Temp (au_id c(15),au_lname c(20),pk I)
>oXML = CREATEOBJECT("wwXML")
>oXML.DataSetXmltocursor(lcXML,"Temp")
>BROWSE
>

>
>
>
>
>Frankly if you do round tripping with DataSets, using anything but .NET on both ends is not worth the effort. You can do this but it would basically involve reverse engineering how data set updates work, which is not worth it, IMHO. In that case you might as well re-design whatever the front end is using .NET because you're already redesigning the app to work with the full offline paradigm.
>
>That's not to say DataSets are not useful in VFP->.NET communication, but in a more traditional data transfer mode.
>
>+++ Rick ---
>