I now have the script running as required on the remote server, apart
from a couple of creases I'd like you to help me iron out. What I
unwittingly held back, and which you would have picked up on straight
way, was my connect routine, to which I added "{ RaiseError => 1,
AutoCommit => 0 }" earlier in the day. It's now obvious I must
either set AutoCommit to true or add dbh->commit() after the execute
line:
my $dbh = DBI->connect("dbi:SQLite:dbname=$database","","", {
RaiseError => 1, AutoCommit => 1 }) ||
print "<p>Cannot connect: $DBI::errstr</p>\n";
# DELETE BUTTON PRESSED
if ($q{BUTTON} =~ s~^Delete[^\d]+~~i){
my $statement = 'DELETE FROM contacts WHERE rowid = ?';
my $sth = $dbh->prepare($statement);
my $rows_affected = "none";
my $rows_affected = $sth->execute($q{BUTTON});
print qq~<p class="temp">( $rows_affected ) record deleted</p>~;
}
Now the first 'crease' is that usually the deletion report reads (1)
row deleted but every so often I get (0E0) rows deleted, and it seems
that the row is deleted all the same.
The second problem is that the list of matching records is recreated
without taking account of the deletion and I need to re-submit the
search string to get a list of hits that takes account of the latest
deletion. How can I avoid this? At the moment I run DBI->connect at
the beginning of the script and disconnect at the end, between which
there will usually be several calls to the database. Should I
disconnect after each call and reconnect or is there a way of
updating the table on the fly?
As to the local server, things are no further forward than when I
first raised the issue. With precisely the same script, database and
module versions the script stops writing at the execute command.
JD
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
