posted May 25, 2000 09:51 PM            

I'd like to use temporary tables to accomplish this because I don't want to have to deal with partial records from people who have decided not to compleat the form.

posted May 26, 2000 09:09 AM            

quote:

---

Originally posted by rycamor:
Yes, I believe you can have a persistant connection, but that is missing the point; The operation can be done without a persistant connection. What I really don't understand is why even bother with temp tables; seems like you're unnecessarily complicating things. You'll have to put too much work into maintaining data integrity.

If I were you I would just push the data from one form to the next, using cookies, or urlencode it (or even the overly simple hidden form fields), then when you reach the last form, do one INSERT that writes the whole record. You might have to put a bit of thought into error handling, but not nearly as much as mucking about with temp tables.

---

But is this practical for forms with 100 or more elements? The elements are placed in the form dynamically, in random order, and in some cases, respondents will have additional questions depending on previous responces. So with a 100 question form, there will be at least 200 numbers to pass. That's way too many for cookie or URL.

[This message has been edited by jake (edited May 26, 2000).]

posted May 26, 2000 02:22 PM            

That said, persistent connections have nothing to do with this subject. All that a persistent connection does is maintain the webserver <-> SQL server connection after the script is finished executing to relieve the overhead of establishing a connection. Your scripts still have to maintain the data integrity of user state, persistent connections can't do that for you.

posted May 26, 2000 03:25 PM            

quote:

---

Originally posted by rod k:
Yes, with that many you probably should have some form of temporary table with a cron job expiring unfinished transactions after a set amount of time.

That said, persistent connections have nothing to do with this subject. All that a persistent connection does is maintain the webserver <-> SQL server connection after the script is finished executing to relieve the overhead of establishing a connection. Your scripts still have to maintain the data integrity of user state, persistent connections can't do that for you.

[This message has been edited by rod k (edited May 26, 2000).]

---

Yes, user state is what I was thinking of.

The cron job thing is the only other conclusion I had come up with, so it's good to know you think the same, then I'm on the right track...

Thanks

posted May 27, 2000 07:18 AM            

wouldn't javascript in a frameset do what you are asking? You could build dynamic forms and store the info as the user moves from form to form.