Once upon a time, journals would delete when all statements were
closed.  I find now to get all journals to delete you must also close
all connections(opens). Figure at some point someone decided it was
more optimal to leave journals around instead of recreating them on
every statement (which it is).

On Wed, Dec 9, 2015 at 1:05 PM, R Smith <rsmith at rsweb.co.za> wrote:
>
>
> On 2015/12/09 10:55 PM, Richard Hipp wrote:
>>
>> On 12/9/15, R Smith <rsmith at rsweb.co.za> wrote:
>>>
>>> One of our systems suddenly started to play up after upgrading to 3.9.2
>>> from 3.8.8 (so I am not sure exactly when the oddity was introduced).
>>>
>>> SQLite:
>>> v 3.9.2 linked on WIndows (various versions) in a 32 bit application via
>>> the exact 32bit DLL published on the downloads page on sqlite.org.
>>>
>>> The error:
>>> During an update to an attached DB, the statement fails and reports
>>> "Disk I/O Error" and leaves a hot journal (even though the statement
>>> wasn't in an explicit transaction).
>>>
>> We can make a script to do this.  And we get this error (when we
>> enable logging - https://www.sqlite.org/errlog.html - which you really
>> should do too).
>>
>> {SQLITE_IOERR_DELETE {os_win.c:39624: (32)
>> winDelete(C:\Users\drh\sqlite\sqlite\
>> test2.db-journal) - The process cannot access the file because it is being
>> used
>> by another process.}
>>
>> The problem is that one connection is trying to delete the journal
>> file that the other connection is holding open.
>>
>> The thing is this:  We can reproduce this going all the way back to
>> version 3.8.0 (which is as far back as I looked.)  So I don't know how
>> you managed to get it working on your 3.8.8 version.
>
>
> This is slightly confusing - I think perhaps other actions we do allowed it
> to slip through (or perhaps complete the deletion before the other file
> access) in our code. But that is just me guessing now.
>
> Also, apologies for the laziness - I would have switched the logger on (we
> do have that of course) but I simply stepped through the code, saw the
> return value, went back to the connection origins, saw the different modes,
> corrected it and then things worked, so I did not do a full analysis, but
> decided it's probably worth reporting it.
>
> I'll do better next time before reporting :)
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to