in reply to DBI: table locking

For the sake of completeness, in case any other monk happens upon this thread in future years, I shall mention here the solution that I've settled on, after reviewing above and some comments in the CB:
$dbh->do("LOCK TABLES tbl WRITE"); $dbh->do("INSERT INTO tbl VALUES(NULL,'foo','bar')"); my $ref = $dbh->selectcol_arrayref(" SELECT LAST_INSERT_ID() FROM tbl"); $dbh->do("UNLOCK TABLES");
This is not the best solution. The best solution would be either PostGreSQL, or getting transactions to work in MySQL. But given where I'm up to with the project I'm working on I'm going to have to live with the second-bestness of it. A bit of a sledgehammer to crack a nut... but it DOES crack the nut!

Thanks again to all those who've helped me with this.

update: crazyinsomniac /msg'd the following even better alternative:

from DBD::mysql
DATABASE HANDLES The DBD::mysql driver supports the following attributes of database ha +ndles (read only): $infoString = $dbh->{'info'}; $threadId = $dbh->{'thread_id'}; $insertId = $dbh->{'mysql_insertid'} These correspond to mysql_info(), mysql_thread_id() and mysql_insertid +(), respectively. insertid MySQL has the ability to choose unique key values automatically. If th +is happened, the new ID will be stored in this attribute. This attrib +u +te is not valid for DBD::mSQL. An alternative way for accessing this +a +ttribute is via $dbh->{'mysql_insertid'}. (Note we are using the $dbh + +in this case!)
So, each instance of your script will have its own database handle, and will only do one INSERT, so the 'mysql_insertid' will be the right one. There is no chance of the insertid being that of a subsequent INSERT that a different process performed (you're not sharing the handle, mysql will not fuck up in this manner).

§ George Sherston