While working on numerous WebForms applications that map data back and forth to a SQL Server 2000 database, I've investigated various options - CSLA, native/custom code, and the DataSet designer - for mapping between datagrids and detail views/form views. My intent and expectation was to prove the validity of the designer-based DataSet/DataTableAdapter methodology for mapping data to and from the database. I even went as far as to work up my own custom stored procedures, so that the problems associated with the generated SQL wouldn't be an issue.

I'm not happy with the results. I've found that, to my chagrin, the dataset/tableAdapter combination - the method I hoped to prove elegant enough for prime time in my enterprise environment - was lacking the implied functionality. Here's a quick run-down of my experiment, paraphrased for the sake of brevity.

I have a stored procedure, called GetPeople. That procedure returns a resultset containing the following fields

PersonId
Firstname
Lastname

I also have written insert/update procedures. The parameter listing is dang-near identical to the Get proc. The "procedure signature" (the listing of parameters for both the update procedure) has the following parameters:

@personId
@firstname
@lastname
 

While the Insert procedure lacks the @personId parameter. Of course, this is almost all common sense, and mirrors the situation many of this forum's readers have in place themselves.

Now, when I create the dataset/tableAdapters using the designer, everything looks perfect.

The problem begins when I begin to add ObjectDataSources to my ASPX pages. Think of it this way:

I create an ASPX page. I add an ODS to the page, and specify the DataTableAdapter for the Person datatable. Most of the time, the ODS designer sees the "get" method on the tableadapter object. Nearly all of the time, the ODS fails to infer the InsertPerson method, despite the fact that I have clearly defined insert and update procedures. Furthermore, the ODS's designer has numerous update methods from which I can choose, but none of them work.

The end result is a data retrieval method that works perfectly when retrieving, sorting, and filtering view on the web forms pages, but fail 100% of the time when I attempt to insert or update the database. I know - or am nearly 100% confident - that I"m doing everything perfectly right, as the wizards and designers were made relatively simplistic to use. So I'm confident that something is wrong in the code that is generated, and I am beginning to believe that the tools given to us by Microsoft are not useful, or at least as useful as they were in the 1.1 designer world. I have reviewed, with care, and implemented all of the suggestions found in the thread located at http://forums.asp.net/1217763/ShowPost.aspx. I have also read, re-read, and implemented the suggestions found in thread http://forums.asp.net/2/1109106/ShowThread.aspx. These seem to be the most relevant to my situation, despite the fact that these threads rely on the generated SQL, whereas my situation relies on custom procedures. My current mode of thinking is that the designers generate seriously flawed code. I don't want to give up, but am so close to doing so and abandoning the entire methodology as a result of continued frustration with this model.

Can someone please tell me what I'm doing wrong? Is there a decent tutorial out there to demonstrate the problems? Is there a service pack in the works that will "fix" this framework? Someone please help me!