View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
04397 | Bug reports | Survey taking | public | 2010-06-07 19:56 | 2010-07-06 11:22 |
Reporter | jdalegonzalez | Assigned To | mdekker | ||
Priority | normal | Severity | minor | ||
Status | closed | Resolution | fixed | ||
Product Version | 1.87+ | ||||
Fixed in Version | 1.90RC2 | ||||
Summary | 04397: limesurvey/index.php has a while loop for a query that can only return one row | ||||
Description | Looking around line 714 you'll see.. $result = db_execute_assoc($srquery) or safe_die ("Error loading results<br />$query<br />".$connect->ErrorMsg()); //Checked My assumption is that since there should be only one row in the survey_(id) table for a given token, this while loop really only ever executes once. Which means either a) it will only execute once, in which case the while should be gone and potentially an error check should be added to assert that there is only one row in the result set or b) it can execute more than once, in which case the bug is that $_SESSION['srid'] will just have whatever the last value of srrow['id'] after having been over set however many times the loop executes. Unless it really is the case that the query is allowed to return multiple rows AND that the value for the last row is the only one we want for $_SESSION['srid'] - in which case there must be a more straight forward way to make this happen than looping through all the rows, setting the value over and over until we hit the end. | ||||
Steps To Reproduce | Look and limesurvey/index.php around line 714 | ||||
Tags | No tags attached. | ||||
Bug heat | 6 | ||||
Complete LimeSurvey version number (& build) | 8488 | ||||
I will donate to the project if issue is resolved | |||||
Browser | all | ||||
Database type & version | all | ||||
Server OS (if known) | all | ||||
Webserver software & version (if known) | all | ||||
PHP Version | all | ||||
I am not really sure if there is a way to get a token in the response table more than once. If i remember correctly there are scenario's where this might happen. When that is the case, probably the last inserted one is the one we are looking for as it should be the most recent one. Ofcourse the sql could be updated to return only the last row, but it is not much of an optimisation as we don't save a db call, but only a little on the loop. Leaving this open for now, as it is something to have a look at but not urgent. Left a @todo in the code. @jdalegonzalez: Keep sending reports like this, we intend to do optimisation when 1.90 is released. If possible, please report bugs on 1.90(RC1) as the code has changed a lot including some optimisations but probably also creating new opportunities to cleanup. |
|
@mdekker - Thanks for the note. I was wondering if my bug reports had reached the annoying stage yet. re: RC1 - I haven't looked at it since the project I'm working on is using the shipping version but I'm happy to. |
|
mdekker, use $connect->GetOne instead. |
|
Fixed in svn 8855 |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2010-06-07 19:56 | jdalegonzalez | New Issue | |
2010-06-07 19:56 | jdalegonzalez | Status | new => assigned |
2010-06-07 19:56 | jdalegonzalez | Assigned To | => user372 |
2010-06-07 23:11 | c_schmitz | Assigned To | user372 => mdekker |
2010-06-14 12:33 | mdekker | Note Added: 12218 | |
2010-06-14 12:33 | mdekker | Status | assigned => acknowledged |
2010-06-14 20:09 | jdalegonzalez | Note Added: 12219 | |
2010-06-17 00:51 | c_schmitz | Note Added: 12239 | |
2010-06-17 12:48 | mdekker | Note Added: 12246 | |
2010-06-17 12:48 | mdekker | Status | acknowledged => resolved |
2010-06-17 12:48 | mdekker | Fixed in Version | => 1.90RC2 |
2010-06-17 12:48 | mdekker | Resolution | open => fixed |
2010-07-06 11:22 | c_schmitz | Status | resolved => closed |
2010-10-25 00:18 | c_schmitz | Category | Survey at Runtime => Survey taking |