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, =dn -- 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]
