State compromise client/server
Printed From: Web Wiz Forums
Category: General Discussion
Forum Name: General Discussion
Forum Description: General discussion and chat on any topic.
URL: https://forums.webwiz.net/forum_posts.asp?TID=12554
Printed Date: 01 April 2026 at 3:23pm
Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com
Topic: State compromise client/server
Posted By: theSCIENTIST
Subject: State compromise client/server
Date Posted: 16 November 2004 at 3:15am
|
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. ------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com |
Replies:
Posted By: Mart
Date Posted: 16 November 2004 at 4:15am
| Cookies can only hold a very small amount of data (it's something like 1kb, can't remember off hand and google doesn't know). You could just set the fields of the table to allow NULL fields and just insert the data you have at each stage |
Posted By: theSCIENTIST
Date Posted: 16 November 2004 at 4:31am
|
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. ------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com |
Posted By: Mart
Date Posted: 16 November 2004 at 4:39am
|
For the ID number problem you just insert then use @@IDENTITY (that's
with SQL Server) not sure if there is an equivalent in mySql. For the second problem you could just have an automated script that ran at 3am in the morningor something and deleted incomplete applications (not the best solution though) |
Posted By: the boss
Date Posted: 16 November 2004 at 4:41am
|
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 :) ------------- http://www.web2messenger.com/theboss"> 
|
Posted By: Mart
Date Posted: 16 November 2004 at 4:52am
| Things will be 1000x easier with asp.net 2.0 and the wizard control lol |
Posted By: theSCIENTIST
Date Posted: 16 November 2004 at 5:22am
|
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. ------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com |
Posted By: dpyers
Date Posted: 16 November 2004 at 7:40am
|
IIRC, a cookie can be up to 4kb. I've done insurance applications like this. Kept things in a session object with routines to serialize it to a db and to load the session from the db. Used xml. Multi-keyed it by drivers license, ssn, and session id. Client cookie just contained keys. ------------- 
Lead me not into temptation... I know the short cut, follow me. |
Posted By: michael
Date Posted: 16 November 2004 at 9:57am
|
I would not even worry about a autonumber. I am sure your users have to login or something, basically having a username. Just take the username as your PK as it has to be unique right? There is no real reason to use a Integer field in your temp table. If there are FK's just relate them to the username which you always know in your application. ------------- http://baumannphoto.com" rel="nofollow - Blog | http://mpgtracker.com" rel="nofollow - MPG Tracker |
Posted By: theSCIENTIST
Date Posted: 16 November 2004 at 4:34pm
|
Actually there's not going to be a login, this application will be available to anons who maybe interested in the service, then they will go about filling the forms.
Submitting the 1st form is not a problem, a autonumber is be generated and I need to know it so the 2nd and all the others can relate to it. Either that, or I store all info in cookies and at the end submit the whole thing. 4KB cookie limit is enough for my data, however I still don't know if this limit applies to the whole cookie, or to the size of the individual key's data. ------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com |
Posted By: dpyers
Date Posted: 16 November 2004 at 4:48pm
|
The 4kb thing is for the whole cookie, but you could have a cookie for each page. -------------
Lead me not into temptation... I know the short cut, follow me. |
Posted By: Mart
Date Posted: 16 November 2004 at 4:54pm
|
But if you do that your going to have a problem if someone has cookies disabled and does not know how to enable them. You could write instructions though I suppose |
Posted By: theSCIENTIST
Date Posted: 16 November 2004 at 11:34pm
|
Last 2 posts relate well to my current stage.
Been testing the forms and hitting them quite hard, all fileds with full capacity, and after page 4 cookie size was exasted, so I decided to add a cookie per page, all works fine now. Then I went to issue of users with cookies disabled, so I set a cookie, then read from it and act accordingly, problem is, that I disable cookies in my browser, and it still sets/reads it, tried many other things, delete all cookies, manually delete all cookies ;), change cookie name so it starts afresh, still the browser sets/reads normally, whats is going on? Could it be that I using localhost and not a domain? Also what would be the best way to test for cookies? ------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com |