really long asp/sql question... if you're bored, come on in :)

Discussion in 'OT Technology' started by umop apisdn, Oct 15, 2005.

  1. umop apisdn

    umop apisdn What has 1000 tits and flies?

    Dec 18, 2004
    Likes Received:
    [Boston] :noitacoL
    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 :)
  2. Astro

    Astro Code Monkey

    Mar 18, 2000
    Likes Received:
    Cleveland Ohio
    Sessions are ok. They're the poor-man's way, in my opinion. You go with sessions, and you chew up all your webserver's memory.

    Thought: why not toss the form results into the next form as hidden form fields? You keep doing this until the last page. On the last page, the submit will then collect all the data and toss it into the database. In some situations this won't work. Like: if you're using GET instead of POST or if the data is mission critical and you're worried about hackers.

    If the above won't work, then maybe look into a form cache table. In the table, have something like:

    ID to identify the user
    the form field name
    the form field value (data the user entered)

    For each submit, you toss data in this table. When the user hits the final page, you collect its data and pull out whatever else is in this table. Problem here is you might want a script to run every now and then to do house cleaning to clean up the gunk that people entered, but then abandoned the form.

    Of course, if you're in a pinch, then session variables will work. But keep in mind the number of possible users and the amount of data you're working with. You may stress out the web server...

Share This Page