My suggestions: Whenever the scouting input page is loaded, it should query the database and fill out all the values on the webpage with the data stored in the database for that match and robot. Clicking submit would then overwrite the old data with the new data. To make multi-user simultaneous entry work, we need to have a way to identify what robots each scout is scouting. Adding a scoutLock and lockTime field to the matchRobotData table could accomplish this. The scoutLock field would indicate what username is scouting this robot and the time the scout took out that lock. In order to set the lock, we need to add functionality to allow scouts to indicate what robots he or she will be scouting. This could be done by adding a checkbox above each of the six robot scout boxes on the scouting input page. When the page initially loads, the six scouting input areas will be grayed out and the scout can only check the select boxes to indicate what robots he or she will be scouting. Once the scout hits the "Submit My Robot List" button, the page will reload and the scout can enter values for those robots. If another scout submits the same robot(s) to be scouted, his or her page will reload and only the robots not already accounted for will be available for data entry. Additionally, the scouting input page should display the username of who is scouting what robots. This will help solve the problem of forgetting to scout a robot, because an unscouted robot will not have a scout username assigned to it. Now, if for some reason, a scout selects to scout a robot and doesn't, someone needs to be able to get in there and enter the data after the match. This can be accomplished by only allowing the lock to be valid for a short time, such as two minutes. (Each time someone tries to submit scouting data, the username should first be compared to the scoutLock name, if they match, the submit succeeds. If the usernames are not the same, check the lockTime. If the current time is later than the lockTime plus the scout lock timeout constant, allow the submit, otherwise, return an error message stating you are not scouting this robot.) To further safeguard the overwriting of scouting data, we could add a uniqueID field to the matchRobotData table. Each time someone updates that row, this field would be written with a new random ID. This ID would be written to a hidden field for each robot in the scouting input page. Upon submit, the ID stored in the form and the ID in the database would be compared. If they don't match, someone else updated that robot's data between the time you loaded the page and the time you changed the data and hit submit. The scouting input page would display an error message stating the discrepancy and it would display the robot's score from the database in the scouting page. The user could then do nothing to keep the score that someone else entered or else re-enter his/her data for that robot and overwrite what is in the database. Got it?! Brandon -----Original Message----- From: Ryan McElroy [mailto:ryan@xxxxxxxxxxxxxxxxx] Sent: Tuesday, February 07, 2006 11:27 PM To: stamp@xxxxxxxxxxxxx Subject: [stamp] Database entry I think there is something about the overall design of this app that I am not understanding. When the match input page comes up, is it supposed to be filled with the last version of the match info submitted? If we want that to happen dynamically, someone with more (ie, any) AJAX experience should probably do it. Also, what do we want to happen when we submit? Overwrite whatever is there with the stuff just submitted, or try to intelligently figure out what should be updated (ie, things with zeros should not be updated?)... I guess the crucial question is is there single-computer input or multi-computer input for a single match? If the latter, how are we dealing with inconsistencies? Stephen, I haven't taken a look at your database classes, and I don't have any experience using things of the sort (I'm more of a PHP hacker than a PHP programmer). So, I'd like your opinion on how helpful you think they will be in this case, and perhaps the best way to use them (maybe a mini-tutorial?) Thanks, ~Ryan