>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.

If you use primarily stored procedures for data, DataSets are not a big help for updates and you'll have to do this manually. You can however set the INSERT and UPDATE commands of the dataset which can call back into the stored procedures to perform updates. Also you can probably (haven't tried this) use stored procs to retrieve the data and plain DataSet updates via SQL statements to update the data on the server if that's possible. Both options are there.

I think the disconnected architecture greatly discounts the need for store procedures with the idea being that the business layers handles much of the logic that goes in to SPs. I personally have never been a big fan of SPs becuase the language sucks and is too limited. It is faster, but in a disconnected environment the performance gain is not nearly as important as having easy ways to move the data around.

But if you do use stored procs, then why are you pulling the data with DataSets in the first place? Why not go straight over HTTP to the data source and retrieve the data into the Fox app either via SQL's built in XML features or via a middleware piece that servers your business object data to you from the Web server?

I do this sort of thing for my business objects, which run local, but access data on the Web. In this case the middleware piece is Web Connection with an HTTPData connector that feeds all SQL through the Web and marshals the SQL commands to the backend. This works the same for stored procs or any explicit SQL commands.


+++ Rick ---



>
>~~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 ---
>>