Still trying to find a "best practices" way of doing things ... just "playing" for now, trying to get a handle on how to do things ... but we'll need to get going on a project soon.

We're gonna use Stored Procedures on the backend, mainly for consistent control of the data, more than anything else ... with shrink-wrapped software, you don't own the data, the customer does ... we want to make it easier for the customer to access his data (of course, we will also have WebServices that do this as well). We are planning on a middle-tier business object to handle the data access and this will be server-side. The UI will be both Windows forms and Web forms. I thought that binding WinForm controls to data was easier to do with DataSets (typed DataSets is what we plan to use), or at least this is what I've read about. Consequently, the WinForms objects will access the data through a WebService (which will pass XML back and forth, not a dataset) and be converted to a typed DataSet for use locally, sending XML back to the WebService which will pass it back to the DataAccess layer, which will figure out how to call the StoredProcedure. Whew ... it *does* seem like a lotta work! <g>

As I said ... what is the "best practice" way of doing things is still up in the air ... we're all learning this stuff. <s>

~~Bonnie


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