On Sunday 08 August 2004 8:32 pm, Scott Leighton wrote: > > Solved! Just to close the loop on this for the benefit of any other > DBD::SQLite users who may be trying to upgrade from v 0.31 to v 1.x.x. > Watch out for cases where your former working code left unfinished SELECT > statements since under SQLite v 3.x.x they will hold locks on the database > causing subsequent SQL calls to fail. > > In my case, the code had several instances where we knew there could > only be one result to the query so we basically grabbed that result and > moved on, e.g., > > $sth = $dbh->prepare($statement); > $sth->execute; > return $sth->fetchrow_arrayref; > > This left the SELECT statement in a not finalized state and the dataset > locked. Worked fine under SQLite 2.8.xx but it fails under 3.x.x. We had to > change the code to, > > $sth = $dbh->prepare($statement); > $sth->execute; > my $result= $sth->fetchrow_arrayref; > $sth->finish(); > return $result; > > to solve the problem by finalizing the SELECT so the lock came off the > database. > > Hope that helps someone else from banging their head against the wall > searching for the problem <g>. Again, a big thanks to D. Richard Hipp for > pointing me in the right direction! >
Follow-up to this thread. The issue with DBD::SQLite 1.00 - 1.03 has been resolved as of DBD::SQLite 1.04 so the above information is no longer applicable. If you are reading this in the archives, ignore this thread. The 1.04 version will act the same as the earlier SQLite 2 versions of DBD::SQLite ( 0.3x versions). Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.104-default x86_64
