On 10 May 2017, at 6:31pm, Ward WIllats <sqlite-us...@wardco.com> wrote:
> I guess with corruption, all bets are off I see your results from "pragma integrity_check". As you write, "all bets are off". If your database is corrupt, any operation on it might silently lead to more corruption. It may just happen that your INSERT command doesn’t do anything involving a contradiction in the file, whereas the SELECT command notices two things which contradict each other so is able to definitively report corruption. You should reconstruct the database, then try again. The simplest way to do this is to use the SQLite command-line tool to ".dump" the database to a SQL text file, quit the tool, restart the tool with a new database file, then ".read" the text file. Once you’ve done that, check to see that the results are still smaller than available space (both disk space and max_pages, as you note), run "pragma integrity_check" again. If it reports everything is okay you can proceed. Of course, that doesn’t explain how the database got corrupted in the first place. I assume you’ve read <https://www.sqlite.org/howtocorrupt.html> > Does this seem...well....normal? I mean, I guess with corruption, all bets > are off, but I'm curious as to what the mechanism might be that made a full > error and not a corrupted error pop out. If SQLite tries to exceed max_pages is it meant to report an error and /not/ corrupt the database. If you can reproduce a case where running out of space in a non-corrupt database causes corruption please tell us, since that’s a serious bug which will be fixed. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
