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

There aren't any best practices yet. It's all new and few people are using this stuff in production apps where it's getting worked on. I have some internal stuff I use here that uses datasets for all data transfer and it works well, but it's all .NET - no VFP involved.

While I think that you can do things in VFP, I don't believe it's all that useful to do this unless you have an existing app. If you're starting out new, .NET is the way to go for the Fat client as well.

Stored procs are stored procs and they have their place, just realize that DataSets don't work directly with stored procs. This may not be a problem because you can bypass the stored procs on the server for doing the dataset updates by giving permissions to allow direct updates etc. while allowing the run of the mill users only access to the stored procs. And as I said you can always override the way the UPDATE and INSERT statements are handled by the data sets, but this also negates some of the biggest advantages of datasets - the fact that they can figure this out on their own if the schema is available in the data retrieved.

+++ Rick --

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