> For the record, "delete the journal file" is terrible advice
Agreed. In normal production environment, I wouldn't suggest that. The user was testing a database, and in my own developemtn cycle, its common when developing for a database to be in all manners of chaos states. It was purely a 'gotcha' that has caught me out before - a journal file lingers and locks the system. On Mon, Oct 15, 2018 at 4:03 AM Rowan Worth <row...@dug.com> wrote: > On Sat, 13 Oct 2018 at 00:21, Chris Locke <sql...@chrisjlocke.co.uk> > wrote: > > > > Database is locked > > > > Close your application. Is there a xxx-journal file in the same > directory > > as the database? (where xxx is the name of the database) > > Try deleting this file. > > > > For the record, "delete the journal file" is terrible advice and a great > way to corrupt a database. In the case where a program crashes > mid-transaction, the journal contains information which is crucial for > recovering to a correct database state. And in non-crash scenarios, the > journal should be cleaned up¹. So when you can see a journal file it's > likely that either: > > 1. some program is currently using the DB, or > 2. there was a crash mid-transaction > > Either way, deleting the journal is a wrong move. > > ¹ unless the DB is configured with PRAGMA journal_mode set to TRUNCATE or > PERSIST, in which case you've asked for the rollback journal to linger > around. > > -Rowan > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
