Hi Dennis, what SQLite version and on what platform are you using? There was a bug in SQLite 3.6.13 on Windows where SQLITE_CANTOPEN was incorrectly returned during journal check when race condition between two threads was hit. Also there could be some other software interfering with the journal deletion, which could cause SQLITE_IOERR. Typically TortoiseSVN has the habbit of doing this. While there is mechanism in SQLite to workaround this, it's far from prefect. Known workaround is to use "pragma journal_mode=persist;". If this solves your problems, then you most probably hit this bug.
BTW, I don't know how many people are affected by this journal creation bug, but there's a reliable way to workaround it. The solution would be to detect the "delete pending" state and rename the journal file in that case. This will allow the new journal file to be created and the old one will disappear as soon as the offending application closes the last handle to it. Anyway... don't want to hick your thread :) Best regards, Filip Navara On Tue, May 26, 2009 at 7:51 AM, Dennis Volodomanov <dennis.volodoma...@conceiva.com> wrote: > I sometimes get either a SQLITE_IOERR or a SQLITE_CANTOPEN when issuing > BEGIN IMMEDIATE TRANSACTION or END TRANSACTION, however the database > file is there and is being used by another thread. I thought I'd get the > usual SQLITE_BUSY or SQLITE_LOCKED, but sometimes these file-related > errors come up. > > > > Does anyone know why they come up and what should be the correct logic > to continue? Should (and can it) the operation in question be retried, > as if a BUSY/LOCKED was encountered? > > > > Thanks in advance, > > > > Dennis > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
