I have a table with over 50 columns and hence, the form is rendered in multiple steps. I wish to offer the feature of canceling the changes at anytime during the insert/update but storing the values entered on previous pages inside the session or cookie is not an option because the table has multiple text-type columns. Carrying over previous values as hidden fields is not an option, either. Is it a good idea to create a (real) temp table so the user can carry out his/her changes on this table and once confirmed, the changes can be moved into the main table?

The main table goes as under:

ID (pk/auto-increment)
Description
...

The temp table I'm planning on is:

ID (pk/auto-increment)
DocumentID (ID from the main table)
Description
...

During an insert of a new row using the wizard, the row would be inserted into the temp table first, with DocumentID as 0 and upon confirmation would be moved into the main table. During an update of an existing row in the main table, the row would be inserted into the temp table from the main table, then worked on and then moved back into the main table.

Is this going to be a lot of work or is there a better approach than the above?

TIA

why not just put it into the main table with an unconfirmed status, and then when it's confirmed, change the status

This works for inserting new rows and is definitely less expensive. But for editing existing rows, if the user wants to 'cancel' the changes during the multi-page wizard form, we need to be able to undo all the changes and restore the previous state of values for all the columns. If we already modified the columns during the wizard, there is no way to restore the original values on cancel. If the form was a single page, we could always cancel changes without saving but the wizard saves data for a couple of times (pages) to cover all the columns. Any ideas for editing existing rows with a cancel option for a clean restore?

Thanks,

In your original post you mention that you cannot use sessions for this because there are "multiple text-type columns." A session can store any number of variables. If you can enter something in a form field, it can be stored in a session variable.

How are you passing the user identifying information between the pages of the form now, session or hidden field?

If you don't want to use session variables, I would say that your proposed method of a temporary table is your best bet. It will allow the same code to work for new records and editing existing records.

Here is a link that might help you out, it is a script that will automatically create hidden fields from any variables entered on a previous form page - http://codewalkers.com/tutorials.php?show=28

I do use session for user-identifying fields on this form. But the problem with the text columns on this form is that they are LARGE! They could go upto 65,000 chars each and on a high-traffic website, each user storing such voluminous info in sessions/cookies could lead to the server consuming enormous memory or even crash! That's the only reason why we cannot use session for this form. The reason why we cannot use hidden fields is that the page loses its state (exited) for each step due to page redirection in this case - due to the way the wizard class is implemented for some good reasons such as preventing page-refresh problems that could re-submit the page, etc. To use hidden fields in this case, I would need to store their values somewhere (session/cookie? no. temp-table? maybe) to catch them up in the next step. I use hidden fields on other single-page forms that do not lose state (form posted to itself without exiting/redirection) without any problem.

Thanks,