Google mail seems to have chosen a convenient moment to go AWOL.
I wrote:
print qq~<p class="temp">\$q{BUTTON} was: $q{BUTTON}</h2></p>~;
if ($q{BUTTON} =~ s~^Delete[^\d]+~~i){
print qq~<p class="temp">\$q{BUTTON}=$q{BUTTON}</p>~;
#######my $rows = $dbh->do("DELETE FROM contacts WHERE rowid = $q{BUTTON}");
my $sth = $dbh->prepare('DELETE FROM contacts WHERE rowid = ?');
my $rows_affected = "none"; # default
$rows_affected = $sth->execute($q{BUTTON});
print qq~<p class="temp">\$rows_affected: $rows_affected</p>~;
}
At least there is some progress, but why are the reportedly deleted
rows reappearing when the search is renewed?
The plot thickens.
Before I uploaded the script to
<http://bd8.com/cgi-bin/iceman.pl> I changed the shebang line from
/usr/local/bin/perl to /usr/bin/perl because, the server at bd8.com
is neither reporting Apache version nor giving a proper value for
$^V, Perl's version.
However the script is _apparently_ working on the remote server, in
that it reports 1 row affected, whereas in the home server, running
the latest Apache2 I the script dies at Ç my $rows_affected =
$sth->execute($q{BUTTON}); È and the html code stops there. This
happens whether I use Perl 5.10.0, the Apple installation at /usr/bin
or 5.12.2 at /usr/local/bin. I have made sure that DBI and
DBD::SQLite are fully up to date in both installations. WHat the
situation is on the remote server I haven't yet looked to see, but
the fact is that the script is within a hair's breadth of working
there, whereas here, with the latest and the greatest Perls and
modules it is not.
JD
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
