On Wednesday, 4 September, 2019 16:36, Peng Yu <pengyu...@gmail.com> wrote:
>> Nope. If there was a problem in closing down they can hang around (which >> is their whole point for recovery). Also if a journal mode of "persit" was >> used. But mostly from incorrect closure. >> So check for any -journal, -wal, or -shm files of the same name if you >> want to obliterate a database. >> (Am I missing any others?) >Is there a minimal work example (in software way but not hardware >failure way) to make these extra files stick around upon closing a >sqlite3 session so that I can have a proper test case to make sure I >always delete them? Thanks. The easiest way is to just terminate without calling sqlite3_close on an open database ... as in: #include <sqlite3.h> void main(int argc, char **argv) { sqlite3* db = 0; sqlite3_stmt* stmt = 0; if (sqlite3_open_v2(argv[1], &db, SQLITE_OPEN_READWRITE, NULL) == SQLITE_OK) { printf("Opened database %s\n", argv[1]); if (sqlite3_prepare_v2(db, "BEGIN IMMEDIATE", -1, &stmt, NULL) == SQLITE_OK) if (sqlite3_step(stmt) == SQLITE_DONE) { printf("BEGIN IMMEDIATE\n"); sqlite3_finalize(stmt); if (sqlite3_prepare_v2(db, "create table crap(crap);", -1, &stmt, NULL) == SQLITE_OK) if (sqlite3_step(stmt) == SQLITE_DONE) printf("Leaving behind open transaction\n"); } } } If the main file is "test.db" then you also have to delete "test.db-journal", "test.db-shm" and "test.db-wal" if they exist. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users