Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 6, 2006, at 9:01 PM, Ron Savage wrote:

> On Mon, 6 Mar 2006 18:28:11 -0600, Puneet Kishor wrote:
>
> Hi Puneet
>
>> [Mon Mar  6 18:23:27 2006] index.cgi: DBD::SQLite::db prepare
>> failed: no such table: sessions(1) at dbdimp.c line 269 at
>
> The fact that the table is called sessions(1) and not sessions is the  
> clue to
> follow first. Check the SQL used or generated.
>

unfortunately that is no clue at all, or at least that I can  
comprehend. The offending line is in: CGI/Session/Driver/sqlite.pm line  
41

34= sub store {
35=     my $self = shift;
36=     my ($sid, $datastr) = @_;
37=     return $self->set_error("store(): usage error") unless $sid &&  
$datastr;
38=
39=     my $dbh = $self->{Handle};
40=
41=     my $sth = $dbh->prepare("SELECT id FROM " . $self->table_name .  
" WHERE id=?");
42=     unless ( defined $sth ) {
43=         return $self->set_error( "store(): \$sth->prepare failed  
with message " . $dbh->errstr );
44=     }
..

as is evident from above, the table name is being passed to store() as  
$self->table_name. I believe the (1) in "sessions(1)" is just how the  
error trace outputs (I really don't understand these things very well).  
There is more clue in the DBI trace

 >>     -> execute for DBD::SQLite::st (DBI::st=HASH(0x9818f0)~0x990bec  
'7c98910b13164f53bc2df9024783e5f2') thr#800200
 >> sqlite trace: bind into 0x990c34: 1 =>  
7c98910b13164f53bc2df9024783e5f2 (0) pos 0
 >>  at dbdimp.c line 443
 >> sqlite trace: Execute returned 1 cols
 >>  at dbdimp.c line 391
 >>     <- execute= '0E0' at DBI.pm line 71 via  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session.pm line 664
 >>     -> fetchrow_array for DBD::SQLite::st  
(DBI::st=HASH(0x9818f0)~0x990bec) thr#800200
 >>     <- fetchrow_array= ( ) [0 items] row-1 at DBI.pm line 73 via  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/
        Session.pm line 664
 >> [Mon Mar  6 18:32:33 2006] index.cgi: DBD::SQLite::db prepare  
failed: no such table: sessions(1) at dbdimp.c line 269 at />>  
usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.

As is evident from above, the "SELECT id FROM sessions WHERE id=?"  
statement is executed with the session id  
'7c98910b13164f53bc2df9024783e5f2' passed for querying. I even get back  
one col as is evident from

sqlite trace: Execute returned 1 cols

and 0 items

 >> fetchrow_array= ( ) [0 items] row-1

because there is no value stored yet. Everything fine thus far. And  
then, failure "during global destruction"!

What puzzles me is that this couldn't possibly be something new. I am  
prone to believe that I am doing something wrong... surely, others must  
be using SQLite as the sessions store, and CGI-Session has been around  
for a while. I couldn't possibly have discovered a show-stopper bug.



--
Puneet Kishor