Hi Jimmy,

> >> 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...
> calling last_insert_id() after INSERT is the number one rule
> of course :)
> What i mean was, what if the INSERT query fail, but the script still
> execute the last_insert_id() function?
> Most probably the returned value would be wrong, because it will
> return the last_insert_id of previous INSERT query (from previous
> 'session')

="right living" was a (poor) joke following your previous post's .SIG file 
aphorism...not a criticism. Now that
you have mentioned the possibility, I can imagine the odd (very odd) use for 
collecting an ID from a preceding
interraction (with the database).

="session" is not the correct word/its use is potentially confusing (perhaps that's 
why it's in quotes?) -
persistence refers to the continuing connection between PHP and MySQL.

> > =What I have noted is that the PHP manual
> > (http://www.php.net/manual/en/function.mysql-insert-id.php) works
> > slightly differently (and possibly more simply), as well as
> > emphasising the "immediately after" relationship between this call
> > and the preceding INSERT.
> I might be wrong, but i think PHP's mysql_insert_id() must be using
> MySQL's API function call.
> Meaning, it will return whatever value MySQL return.
> Or in other word, mysql_insert_id() and last_insert_id() will return
> the same result.
> I have look thru the manual link above, and i think the phrase
> "immediately after" in the manual is more to advise the user to do
> mysql_insert_id() immediately after the INSERT query,
> because last_insert_id value might get overwritten by the newest one.
> the "immediately after" phares in the manual doesn't mean that PHP's
> mysql_insert_id() function is somehow tied to the previous/last
> INSERT query, so that if the INSERT fails then mysql_insert_id()
> will intelegently return the correct value.
> just my 1 cent....

=Agreed it would seem perfectly logical that the PHP function simply calls the MySQL 
source function. However it
is also possible that in order to save time the LAST_ID information is built into the 
resultset coming back from
the INSERT - thus when mysql_insert_id() is called PHP would not need to go back to 
MySQL/last_insert_id(). On
the other hand, the apparent differences between the two manuals may simply be in the 
expression of two
authors... I don't know [but would welcome competent advice!]

=the "immediate" advice is transparently logical "best practice".

=I'm not sure that I've understood your last point. The comparison/difference, as I 
read/understood it, is that
if the INSERT works then both functions will operate correctly. However if the INSERT 
fails, then MySQL's
last_insert_id() will return the ID of the last record successfully inserted during 
the connection (whenever
that was) - without necessarily any recognition of an immediately preceding failure. 
Whereas PHP's
mysql_insert_id() is keyed to the resource identifier and returns zero if the 
**latest** INSERT failed for some
reason (and the rationale for my earlier comments/comparison).

=My thinking is that the PHP rationale makes the most/safest sense to me, and if I'm 
'in' PHP it seems best to
stick with that 'mode' than to go 'out' to MySQL to find the 'same' answer.

=Intriguing stuff,

PHP General 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]

Reply via email to