State compromise client/server

Hi folks,
I've been asked to revamp some old projects, one of wich had me thinking quite a bit on the best way to achieve the task at hand.

A client wants a large form, 6 pages long, 35 fields each page, 210 total, this ranges from mostly texboxes, some checkboxes and dropdowns, and a textarea. I will be using MySQL backend for this one as in MSSQL it would take several MBs to start off with a blank DB/Table.

My first thought was, how am I going to maintain state between pages? Because it will only be submited after the last page, and all the info must be remembered. I considered using session vars, but this would take alot of memory out of the server just to hold all that info before submiting. Then I decided to go for cookies, this way it takes the toll on the client side, is it viable to proceed with the cookie option? Everything works fine so far, what problems can I expect?

Thanks.

Holy cow, 1KB, is that for the whole cookie, or per key?

I'm using only 1 cookie with many keys to store data, if the limit is per key, then I should be alright as 1KB is more than enough.

I have set the table to allow nulls from the start just in case something goes wrong with validation, but if I insert data per page, I will have 2 problems:

1. The ID (auto_increment) column does not allow me to retreive it's value so I won't know which ID to insert the other pages on. Unless there's a way to know which ID the auto_increment column has been assigned, so I can pass it along and insert subsequent pages on it.

2. If the user gives up 2/3 pages down, my client ends up with an incomplete application.

Suggestions please.
All but NO session vars.

Thanks.

store it in a temporary table.. and a boolean value to define if the form was completed.. when the last page is submitted.. the boolean will be set to True and then the underlying script on the last page form handler will extract that data out of the temporary table and put it in the final table.. this way any form which will left incompleted will stay in the temproary table and hence the temporary table can be purged from time to time where as the data collection in ur final table will be all complete

this also allows the flexibility to user to go back and alter data he/she enterned in the previous page.

offcourse there should be a unique ID to "remember" the information indivisually and this can be provied with a cookie or session :)

Edited by the boss

Temp table, what a great idea, I used to do things this way a few years back, how couldn't I remember it? Thx.

Still have the problem to retreive the current record auto generated ID on MySQL, will have to look into this, I usually prefer MSSQL for large or very busy databases, but this DB even empty will take up 5-10 MBs of space as for the same in MySQL it takes only 28 KBs ;) ... It's good to have both back-ends at your disposal.

Yeah, even with the current ASP.NET we have better ways of dealing with this issues, the problem is I have not yet decided to go .NET full time and I'm really pressed for time on this one so can't try/test as I go even if this is a small and good little app for that.