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

Reply via email to