«

Hey guys,

I currently have a giant client editor form in ASP/SQL. The form is
fine. The problem is that there are several sub-forms that store their
data in other tables. Which gets cluttered. For example, I can't let
users add data in these sub-forms until the main form is completed and
an autonumbered ID is generated.

We're taking a few months out of new developments to go back and fix a
bunch of things (like this), and I was wondering what the best way
would be (if anyone has run in to a similar issue) to allow a large
editor that touches multiple tables to have one giant master "Save"
button that validates everything and that doesn't make changes until
it's clicked.

Sadly, transactions are unable to span across multiple pages (and I
don't wanna store recordsets as session objects), and they wouldn't
work anyways, since in the event of new additions, I would need to wait
until I have that autonumbered ID generated before I attempted to store
anything in one of the smaller tables.

I was thinking of perhaps session variables that corresponded with the
names of the tables that I was working with that had an array of data
that corresponded with {fieldName} => "Value," and then loop through it
and validate it, then execute the appropriate SQL.

Cliffs: In ASP/SQL, does anyone know of some industry-standard way to
have one "Save" button store data collected through multiple pages,
assuming that in some cases, when adding a new record, we'd need to get
the value of the autogenerated "ID" field first before saving data that
affects other tables?

Wow... what an obnoxiously long question. If you're bored, feel free to
read through

"Tim Feeley" <> wrote in message
news: oups.com...
> Hey guys,
>
> I currently have a giant client editor form in ASP/SQL. The form is
> fine. The problem is that there are several sub-forms that store their
> data in other tables. Which gets cluttered. For example, I can't let
> users add data in these sub-forms until the main form is completed and
> an autonumbered ID is generated.
>
> We're taking a few months out of new developments to go back and fix a
> bunch of things (like this), and I was wondering what the best way
> would be (if anyone has run in to a similar issue) to allow a large
> editor that touches multiple tables to have one giant master "Save"
> button that validates everything and that doesn't make changes until
> it's clicked.
>
> Sadly, transactions are unable to span across multiple pages (and I
> don't wanna store recordsets as session objects), and they wouldn't
> work anyways, since in the event of new additions, I would need to wait
> until I have that autonumbered ID generated before I attempted to store
> anything in one of the smaller tables.
>
> I was thinking of perhaps session variables that corresponded with the
> names of the tables that I was working with that had an array of data
> that corresponded with {fieldName} => "Value," and then loop through it
> and validate it, then execute the appropriate SQL.
>
> Cliffs: In ASP/SQL, does anyone know of some industry-standard way to
> have one "Save" button store data collected through multiple pages,
> assuming that in some cases, when adding a new record, we'd need to get
> the value of the autogenerated "ID" field first before saving data that
> affects other tables?
>
> Wow... what an obnoxiously long question. If you're bored, feel free to
> read through

Each form populates hidden fields on the next. When you get to the Master
form, it contains hidden fields with values from all the previous forms. One
submit button on the Master form.


--
John Blessing

http://www.LbeHelpdesk.com - Help Desk software priced to suit all
businesses
http://www.room-booking-software.com - Schedule rooms & equipment bookings
for your meeting/class over the web.
http://www.lbetoolbox.com - Remove Duplicates from MS Outlook
http://www.outlook-find-replace.com - Find & Replace in Emails, Contacts,
Appointments, Tasks and Notes