Ah yes, you should also have a primary key for your answer table to retrieve and update any particular answer (this is why I put a numeric primary key field in every single table I create whether I think I need it or not). Then do SQL select on the SID,QID, and from the retrived result pick the answer you want to update and use it's ,"QAID?" in the SQL Update where clause. Personally, I would not implement a way to change a survey result once entered, just because it is a survey. I would probably store the information the user was entering, and have them confirm that is really what they want and then commit the transaction and that's it. If you must be able to retrieve a particular respondents answers, then another identifier is needed, perhaps the name of the respondent in the answer table. This would make it possible to retrieve all answers to Survey "silly survey" to question "silly question" where respondent's name is "serious man" pick one, and update it. Of course if you let "serious man" take the survey twice things get messy so you would then need to make the survey taker name field unique in another table and then enter it as a foreign key relation/constraint in the Question_answer table. Hope that was clearer than mud.

Just curious, why would you want to do this?