> Le 13 juin 2016 à 15:41, Luc DAVID <lucdavid....@free.fr> a écrit : > > The worst case is when you get a "Database is locked" message which mean you > have to kill all the application processes in order to unlock the db (unless > another means exists ?)
You shouldn't get any such with cautious design. And you shouldn't need to stop all processes to resolve such. What's the programming language used in the application? We make a routine of calling sqlite3_extended_errcode(att) to get the precise errcode from SQLite and use sqlite3_errstr() to get the text translation of it. This might tell you (this is not the actual text, just writing of memory): "517 Busy snapshot" (and others) instead of a more generic "6 Locked". Just an example. Installing a logging function through sqlite3_config(SQLITE_CONFIG_LOG, ...) would prove very useful too. What you might miss too is a busy_handler function or at the minimal configuring the default busy handler with sqlite3_busy_timeout() to configure a longer than default timeout. So that any process attempting a write transaction (using begin immediate for instance) will wait reasonably long enough before abandoning: it needs to wait for some other writer to commit or rollback before proceeding. That, or you handle the BUSY in the application code. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
