> >> 2 because the (function argument) controlling feature is the
> >> connection, it is not possible for another concurrent user to
> >> 'steal' your ID or influence the ID returned to you - it's all
> > Ok, assume you are correct, but what if you are using persistent
> > connections (ie pconnet)?
> don't worry, persistent connection is per-child-process basis,
> so concurrent users will use different connection to DB.
> the only problem i can think of might occur with pconnect is,
> last_insert_id() will return you the last inserted ID from
> previous 'session', not current 'session'.
> to prevent this, you should call last_insert_id() only when
> your INSERT query executed succesfully.
=Of course a "right-living" boy like me, cannot conceive of why one would look up
LAST_INSERT other than
immediately after the INSERT/UPDATE command...
=However this is an interesting thought and you are right. There are differences
between the MySQL
LAST_INSERT_ID and the PHP MySQL_
=The MySQL manual (220.127.116.11 Miscellaneous Functions) talks about "Returns the last
automatically generated value
that was inserted into an AUTO_INCREMENT column...The last ID that was generated is
maintained in the server on
a per-connection basis.", and a number of other if-s, but-s, and maybe-s that will get
=(However I believe it also answer's Martin's question!)
=What I have noted is that the PHP manual
slightly differently (and possibly more simply), as well as emphasising the
"immediately after" relationship
between this call and the preceding INSERT. An interesting point here and that is that
it takes care of Jimmy's
concern: what happens if the INSERT query was successful.
=I think I prefer the PHP approach - and it is probably more efficient/quicker (from
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]