My site has an INSERT into 'table b' based on a value from
'table a 'having SELECT:
ORDER BY ('table a ' time stamp col) DESC limit 1
Then, on the following page, the newly inserted row values from 'table b' are echoed on the page (echo only for the user to see, which is a confirmation page) so it can insert from this pg into 'table a' -- the 'table b' primary ID.
Please note that 'table a' is linked to a 'prior table' by a session variable as a foreign key (these pages all carry the session variable) which happens to be that 'prior table's' primary row ID. The pages with these inserts (as well as update pages) have restricted access by username/password and access levels.
But lately I've heard that under the right situation, even with the table column rows appearing to be echoed correctly; the 'table b' primary ID row may possibly be inserted into the wrong 'table a' row.
Since we are talking about associated rows that are not yet created, and I don't care to use an "after trigger" -- am I concerned over nothing? I've tried testing this out for such an 'insert into wrong row' by two seperate logins simultanesouly but have yet to duplicate this .
Does it really matter if the session is used for variable $HTTP_SESSION_VARS to help prevent this?
Is the only risk with having multiple user logins?
