I'm coming accross a weird error from some deployed code. Several users occassionaly get an unexpected SQLITE_FULL error on calls to sqlite3_step().
It happens infrequently, and I've not been able to reproduce. First some background: - Windows only (seen on XP and Vista) - sqlite version 3.6.23 - Using Shared Cached Mode - Using Read Uncommitted mode - Not using temporary tables - Compiled with SQLITE_THREADSAFE=2 I know for a fact that these users have plenty of HD space (the crash report diagnostics show this). Although I can't rule out a "too large" DB, I'd be astonished if it was too large either in size or row count (we're only talking maximum 100,000's rows, not millions). Always, the users are able to restart and carry on without problems, suggesting this is a transitory issue. What's interesting is that, to my mind, the windows specific code in "winWrite" and "winRead" seems a bit liberal about how it generates SQLITE_FULL errors: it seems to return them simply if a call to SetFilePointer() fails, regardless of the error returned, or if it can't write the expected number of bytes. So, I'm speculating that in my case SQLITE_FULL might actually be because of an IO error which SQLite is incorrectly interpreting? Or if not an IO error, then a system resources problem (I have some other anecdotal evidence to suggest other crashes are related to low system resources). Can anyone concur with this, or suggest other possibilities? Thanks, John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
