Let's say the user connects and fills out a form to create a new record in the Person table. Let's assume the Person table has an AUTO_INCREMENT column named 'id'. When the user clicks submit, the data in the form is submitted to your program which will then lock the table for write and insert the record. Your program then selects the last insert id and unlocks the table so others can write to it. All of that has to happen in one request to the web server. It cannot be done over several connections due to the fact that you can never be sure which instance of DBI you will get.
You can keep track of this id some by storing it in a session or a cookie. This would allow you to reference that id over several connections. Good Luck! Rick Apichairuk > -----Original Message----- > From: Octavian Rasnita [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 04, 2007 12:50 AM > To: Rick Apichairuk > Subject: Re: Apache::DBI > > Ok, thanks, but how can I do that? > > Octavian > > ----- Original Message ----- > From: "Rick Apichairuk" <[EMAIL PROTECTED]> > > > > Octavian, > > > > You are right about the need to use table locks. But you will also have to > > ensure that all of this is happening in one session or one transaction. If > > it > > happens over multiple connections to the server, you can't be sure that > > you will > > get the same DBI object as the prior request. > > > >> -----Original Message----- > >> From: Octavian Rasnita [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, February 03, 2007 3:53 PM > >> To: modperl@perl.apache.org > >> Subject: Apache::DBI > >> > >> Hi, > >> > >> Can you tell me, if I use persistent MySQL connection (with Apache::DBI), > >> if > >> I want to use select last_insert_id(), do I need to lock the table before > >> doing the insert and unlock it after using the last_insert_id()? > >> > >> I don't know what could happen if another user of the application makes > >> another insert right after I do the same thing. I am afraid that it could > >> return its last inserted ID and not mine. > >> > >> Thank you. > >> > >> Octavian > > > > Rick Apichairuk > >
