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