Thanks for the reply,
I will explicitly set the id of the inputboxes. Each form
module (ascx page) will contain a small number of fields.
For example, one ascx file might contain "user address
information" (address, city, state, zip etc). The problem
is we don't necessarily want to always have that info on
the first page of a multi-step form. Maybe one client
will want that info on the second page (combined with
other ascx modules.) Each step might contain 2-4 modules
or ascx files. This will make the process shorter but
since we can move the input groups to different sections,
I can't just write a procedure for each page to update the
database, since the input boxes on those pages could
change. I need a general database update procedure that
can handle a group of fields. Essentially I want to treat
the page as a whole and not individual ascx files.
I just want to see what others think.
>>>>but since the field names and values are dynamic
>Are you referring to the id of the inputboxes? You could
explicity set them
>instead of letting asp.net do so.
>Victor Garcia Aprea
>Microsoft MVP | ASP.NET
>To contact me remove 'NOSPAM'. Please post all questions
to the newsgroup
>and not by private mail.
>> I'm building a web form that will contain multiple
>> per page. (i.e the form will consist of a number of ascx
>> files each containing one or more input boxes and
>> lists. There will also be a seperate ascx page
>> a "submit" button. (The design requirements need the
>> ability to move different sections of the form (i.e. the
>> modules) to different pages etc.) The appearence of the
>> webpage will be that it is one form with input boxes.
>> reality the page will consist of one aspx page with a
>> number of imbedded ascx files. My problem is how to
>> the data into the database. I'm thingking the submit
>> button will loop through the control collection for the
>> form. It will add all input fields to a dictionary
>> or something which will then be used to dynamically
>> an insert/update sql statement. In the past I have used
>> stored procedures to update the database, but since the
>> field names and values are dynamic that solution isn't
>> really viable. I was curious if any of you had done
>> anything similar and had any words of advise or warning.