Thanks everyone for the help. I have had some success. I moved the
script over to the cgi-bin directory and it now works when accessed via
the browser. So it seems that the problem is related to mod_perl. The
below info is when trying to run with mod_perl. I am not sure if it is
worth pursuing since it works as a cgi script though. If anyone has any
ideas it would be appreciated though.
Both the mod_perl and shell script returns the following:
perl version 5.008008
DBI version 1.609
Apache version 2.2.3
Redhat version 5
I took Darren's advice and modified the code as shown below. I also took
out the create table and insert statements and am just testing the
prepare statement. The database is created by running the shell script
to create the table and insert my 1 row. This is the current code:
#!/usr/bin/perl -w
use DBD::SQLite;
print "Content-type: text/html\n";
print "Pragma: no-cache\n";
print "Cache-control: no-cache\n";
print "Expires: Mon, 06 May 1970 04:00:00 GMT\n";
print "\n<body>";
DBI->trace(4, "/tmp/dbitrace.txt");
$db = DBI->connect("dbi:SQLite:dbname=/tmp/test.db", "", "",
{ RaiseError => 1 });
$db->trace(4, "/tmp/dbdtrace.txt");
$sth = $db->prepare("select c1 from xyz");
$sth->execute();
while( $href = $sth->fetchrow_hashref ) {
print $$href{"c1"} . "\n";
}
$sth->finish;
$db->disconnect;
print "</body>";
I no longer get the error printed to the browser but now the error is
redirected into the webserver log file. Using the above I get this in
the error_log:
DBD::SQLite::db prepare failed: not an error at
/home/oracle/bugpush/abc.pl line 16.
[Wed Dec 02 08:06:29 2009] [error] DBD::SQLite::db prepare failed: not
an error at /home/oracle/bugpush/abc.pl line 16.\n
I also took Adam's advice and turned on DBD and DBI tracing as shown in
the above example. The DBI trace file did not have much but the DBD
trace file shows this:
<- trace= 4 at /home/oracle/bugpush/abc.pl line 13 via at
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm
line 204
-> prepare for DBD::SQLite::db (DBI::db=HASH(0x9e41524)~0x9e414e8
'select c1 from xyz') thr#9abe040
sqlite trace: prepare statement: select c1 from xyz at dbdimp.c line 423
sqlite error 21 recorded: not an error at dbdimp.c line 433
<> DESTROY(DBI::st=HASH(0x9dae56c)) ignored for outer handle (inner
DBI::st=HASH(0x9e414a0) has ref cnt 1)
-> DESTROY for DBD::SQLite::st (DBI::st=HASH(0x9e414a0)~INNER)
thr#9abe040
ERROR: '21' 'not an error' (err#1)
<- DESTROY= undef at /home/oracle/bugpush/abc.pl line 14 via at
/home/oracle/bugpush/abc.pl line 14
dbih_clearcom 0x9e414a0 (com 0x9d28c90, type 3) done.
!! ERROR: '21' 'not an error' (err#0)
<- prepare= undef at /home/oracle/bugpush/abc.pl line 14 via at
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ModPerl/RegistryCooker.pm
line 204
It appears that the prepare is returning a sqlite error 21
On 12/1/2009 10:27 PM, Darren Duncan wrote:
Mike Campbell wrote:
Ok here is what I get.
Test using DBD::SQLite (same output when used command-line and via
webpage)
=====================
the SQLite v3 is 1.27
Test using DBD::SQLite2 (same output when used command-line and via
webpage)
the SQLite v2 is 0.33
<snip>
At first glance you seem to be doing things adequately in your code
samples.
However, your code looks very old-fashioned, maybe because you based
it on old code you saw somewhere, and making it into more modern Perl
can probably help.
For starters, when you are using DBI, *always* configure it to throw
exceptions on errors rather than just return nothing.
Instead of this:
$db = DBI->connect("dbi:SQLite:dbname=/tmp/bugpush.db", "", "")
|| die( $DBI::errstr . "\n" );
... do this:
$db = DBI->connect("dbi:SQLite:dbname=/tmp/bugpush.db", "", "",
{ RaiseError => 1 });
That alone should go further towards you getting useful error messages
when you should be.
Also you can remove all your tests like "if(! defined($sth) || !
($sth))" or "if (! defined( $rc ) )".
When DBI is set to throw exceptions, you can just code as if each step
will work and you don't need to test, since the program should die by
itself if something goes wrong.
Instead, you just do tests when you want the program to not die but
rather be more graceful when something goes wrong, and then you do it
by setting up an exception handler (an "eval" block), but we don't
need to get into that now.
So try making those changes and see what effect is has.
I'm not immediately in the position to run your code myself, not
having mod_perl installed.
It would be helpful if you could provide more information on your setup.
What versions of Perl and DBI are you using, to start with.
To find out, you can use code like this:
my $perlvers = $[;
use DBI;
my $dbivers = $DBI::VERSION;
Run that on both command-line and mod-perl as usual.
Also your versions of Apache and mod_perl are useful to know.
Also try running your code under FastCGI, or CGI, rather than mod_perl
and see if that has any effect on the result. Include the tests for
what DBD::SQLite/etc version is running if necessary.
Maybe someone else on this list has ideas?
-- Darren Duncan
--
Mike Campbell | Principal Support Engineer | 407.458.2313
Oracle Support Services
7453 TG Lee Blvd. | Orlando, FL 32822
_______________________________________________
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
