Re: [sqlite] sqlite3_close_v2 leading to database corruption

> On Feb 7, 2018, at 12:34 AM, Clemens Ladisch wrote: > > Java's garbage collection handles memory. For any other kind of > resource, you should use try-with-resources statements. Yes, like the way our .NET API uses IDisposable. But we can't _force_ developers to use try-with-resources, and

Re: [sqlite] sqlite3_close_v2 leading to database corruption

On 02/07/2018 07:25 AM, Jens Alfke wrote: On Feb 6, 2018, at 4:13 PM, Simon Slavin wrote: Before you call sqlite3_close_v2(), do this: > and deal with any problems. Actually, I already do

Re: [sqlite] sqlite3_close_v2 leading to database corruption

Jens Alfke wrote: > 3. The database is closed with sqlite3_close_v2. The statement is still > alive, so the database handle secretly remains open in "zombie mode". > 4. We delete the database's parent directory and all files in it. > [...] > This scenario isn't covered in "How To Corrupt An SQLite

Re: [sqlite] sqlite3_close_v2 leading to database corruption

> On Feb 6, 2018, at 4:13 PM, Simon Slavin wrote: > > Before you call sqlite3_close_v2(), do this: > > > and deal with any problems. Actually, I already do that, to log info about the ope

Re: [sqlite] sqlite3_close_v2 leading to database corruption

Before you call sqlite3_close_v2(), do this: and deal with any problems. But actually I think you'll somehow have to force the JVM to run finalizers on the relevant objects. Simon. ___ sqlite-users

[sqlite] sqlite3_close_v2 leading to database corruption

We've been trying to figure out a database corruption issue for a week, and think we've got it figured out. It involves the "zombie database handle" state induced by sqlite3_close_v2: > If sqlite3_close_v2() is called on a database connection that still has > outstanding prepared statements, BL