I actually think that this is a very interesting question and am surprised not to see more comments already in this thread ...

Based on the fairly simple overview of the process in place currently, I think the solution lies within the means by which you store your session and input data. From the overview given, I am guessing you are making use of client-side storage of the data entered within the 'session', hence the problem when the input train is interrupted. This is where your biggest mistake lies ... Client-side cookies should not be used for any 'real' sessional data storage - Instead, the client-side cookie should only store a unique, and preferably, non-predictive and pseudo-random, pointer to the storage of this data on the server.

How can this work with the given scenario? Well, the answer to this question will depend very much upon the specifics of client cookie management and server-side data storage with your script. However, imagine the following as an order of operation for your application ...

• Client connects to initial interface page of your application where a client-side cookie is set (CGI::Cookie) - The cookie at any stage only contains a unique, non-predictive and pseudo-random identifier (think Digest::MD5) for the session; no data entered at any point throughout the entry process is stored in this client-side cookie.
• The client progresses through the entry pages and data entered is stored server-side, updated at each step throughout the process. This server-side storage need not be complex and could quite simply take the form of a serialised DBM hash, indexed by the unique key stored in the client cookie.
• At the completion of the entry process where the client unchecks the box for further data entry, the server-side data collected for the user session is submitted to your database in the existing manner.

 

This method could be streamlined through the use of a server side session management and data storage solution such as Apache::Session - Indeed, if you really wanted to, you could actually take out the final step of this process by expanding your existing database tables to include sessional identification such that data entered during the session could be submitted to and updated within the database as entered. The expansion of data storage in this manner, paired with a second table matching up client environment details, collected at the time of session initiation, with the sessional identification would allow you to track user-entered data quite precisely.

The approach of pooling data from sessions into half-hour blocks for submission, collectively referring to them as a sessional entered unit, really doesn't scale too well to a system where you might have dozens of people entering information at once. Furthermore, by collecting the data server-side in this manner forms the rudiments of a 'true' sessional system, similar to that described previously.

Good luck

 

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'