On Wednesday, 4 September, 2019 16:36, Peng Yu <[email protected]> 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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
