Hello.
> I suppose I should file a bug report then? Could you provide a repeatable test case for you problem? If you're using LAST_INSERT_ID() in a wrong way, that doesn't mean that there is something wrong with MySQL. Björn Persson wrote: > Gleb Paharenko: > >>So in you query both last_insert_id() should return the same value, >>which equals to the value that was set for an AUTO_INCREMENT column by >>the last INSERT or UPDATE query. Note that you have one query, which >>just inserts several rows, so during it is processed the returned value >>of last_insert_id() is constant, even if your bulk insert is changing an >>AUTO_INCREMENT field. > > > That's what I thought, and on one server I have (4.0.21) it seems to work=20 > reliably that way. On another server (4.1.10a) that kind of insertions fail= > ed=20 > on a foreign key constraint. (I use InnoDB.) On a third box (4.1.14) it see= > ms=20 > to work sometimes and fail sometimes. I think what happens when it fails is= > =20 > that the second last_insert_ID() gets the ID of the first row in the same=20 > query. > > I suppose I should file a bug report then? > > Bj=F6rn Persson > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
