I've been having an ongoing issue with some deployed code (Windows). Occasionally, operations would fail with the SQLITE_FULL error.
I've now tracked this issue down to being caused by other processes (virus scanners) locking the journal file at sensitive times. (I'm fairly certain that the SQLITE_FULL is a complete red herring - in all cases there is plenty of HD space, and the DB isn't that big. If you look in the winXXX file functions, you'll see that SQLITE_FULL is often just returned as the generic error code. Plus I've reproduced this error experimentally). I've managed to reproduce this error with a fairly simple bit of code which just runs in a loop trying to open a non-sharable read handle on the journal file. If it gets it, it holds it for a short period before releasing. What I observe is then sqlite fails with SQLITE_FULL. It fails because it can't open the journal file. It can occur in a variety of places including while performing a "BEGIN EXCLUSIVE" as well as a "COMMIT". What's interesting is that the main DB file is immune to this issue as it keeps a file handle open permanently to this file. So, any other process can't get an exclusive lock. The journal file handle, on the other hand, seems to be opened and closed lazily, hence the problem. My question/issue is this: is there a way to make Sqlite permanantly lock the journal file in the same way? This isn't as crazy as it sounds: you can set JOURNAL_MODE to TRUNCATE, in which case the journal file exists all the time, so it's not inconceivable that you could keep a file handle open all the time. I guess the other issue is that it returns SQLITE_FULL instead of something more useful. Any thoughts, suggestions? John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
