Been using SQLite for a long time and a huge fan. We occasionally see database corruption on a local NTFS Windows drive and I've been trying to figure it out.
I finally have some logs from the SQLITE_CONFIG_LOG callback that may be of help: (11) database corruption at line 78267 of [3d862f207e] statement aborts at 29: [DELETE FROM StatData WHERE StatID IN (SELECT StatID FROM Statistic WHERE OwnerType IN (4) AND OwningComputer='f7ab745b-1aa7-4159-bbf7-b0b4d1262804') AND Date < 1350715577;] This is for version 3.11, and the line is for a OP_NotExists case. There was no power outage or other OS problem, this was not a restored database but had been in use for at least 12 hours. It was not using WAL, and there is only one process using the database file (though multiple threads, but they each have their own database handle). I've been through https://www.sqlite.org/howtocorrupt.html a number of times over the years :) Would it be possible for a file scanning process (anti-virus, backup, etc) to grab hold of a database file at just the right moment, momentarily blocking a write or delete, and causing corruption? There is a greater chance that this is my bug or environmental than being in SQLite, so I'm looking for anything I can do to decrease these occurrences. Thanks for any input. Doug _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
