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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
