I think i found solution. The problem is that DBD::SQlite->disconnect() method execute sqlite3_close() function. This function return SQLITE_BUSY in case if there are any active statement. >From API: "Applications should finalize all prepared statements and close all BLOBs associated with the sqlite3 object prior to attempting to close the sqlite3 object." Currently DBD::SQLite can finalize statements only via DESTROY method.
In simplest case you can always use "undef $sth" or wait untill it goes out of scope which will finalize statement. But if you prepared statement via cache (prepare_cached) it will not work for you, because statement is till inside DBI cache. In this case we can call DESTROY on our cached statement only via DESTROY for database handler. And we can achieve it by "undef $dbh". "undef $dbh" - will close all cached statements and close database without any errors. Conclusion: avoid using $dbh->disconnect() for DBD::SQLite, instead use "undef $dbh". On Feb 5, 2008 3:37 AM, Alexander Batyrshin <[EMAIL PROTECTED]> wrote: > Hello, > > > What do you expect to see? From the code, I'm guessing something like: > > This is "test-case" program for testing DBD-SQLite behavior. Dumper is > only for be sure, that data was read correctly from database. > > > If you're just trying to silence the "closing dbh with active handles..." > > warning, "undef $sth;" usually works for me. I see you have it commented > > in your code? DBD-SQLite has spewed this warning for as long as I can > > remember. And $dbh->finish; doesn't squash it. > > Yes, this is what I want. "undef $sth" doesn't work for statement that > was prepare_cached. Because statement is still allocated inside $dbh > buffers for cached statement. > > > > Also, I see you could save the sprintf and $dbh->quote by changing to: > > > > my $sql = "select a_session from sessions where id = ?"; > > my $sth = $dbh->prepare_cached($sql); > > $sth->execute($sid); > > Yes, i know, but this is only "test-case" program without any > optimization and code-beauty refactoring. > > > In your example, the value of $sid, after doing the $dbh->quote, is parsed > > by the SQL parser. Doing that has always been unreliable for me, and it's > > generally open to SQL injection. In the example above, $sid isn't > > parsed/compiled by SQLite, it's just passed as-is as a bound parameter > > after $sth is prepared. > > What kind of SQL injection is possible here? > > > Are you building a web session manager using SQLite as the data store? How > > is Storable working for you? I usually just use Data::Dumper, and eval the > > stored hash. But doing the eval has always worried me :-)) > > It's work without any problems for me handling over 150k hits/day. > > > > -- > Alexander Batyrshin aka bash > bash = Biomechanica Artificial Sabotage Humanoid > -- Alexander Batyrshin aka bash bash = Biomechanica Artificial Sabotage Humanoid _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
