On 8 July 2017 at 03:28, Yuri <y...@rawbw.com> wrote: > > There are some other problems in error definitions. For example, what does > SQLITE_FULL mean? How can database be full? Is it really a disk-full > condition? > > #define SQLITE_FULL 13 /* Insertion failed because database is > full */
Disk is full, or the database cannot hold more pages[1], or a table cannot hold more rows (because all ROWIDs have been used). [1] https://sqlite.org/limits.html#max_page_count > Also, what does > >> #define SQLITE_IOERR_SHORT_READ (SQLITE_IOERR | (2<<8)) >> > really mean? How is it different from the case when database is > corrupt/truncated? But there is SQLITE_CORRUPT for that. > Short read mean EOF, and EOF in unexpected place constitutes corrupt > database file. > SQLITE_IOERR_SHORT_READ is mostly of interest to the vfs layer rather than regular sqlite users, because sqlite specifically requires that a vfs implementation zero the remainder of the read buffer in the short read scenario. Interestingly sqlite works quite differently to your expectation in the case of unexpected EOF. Sqlite doesn't automatically assume corruption - in fact this is the one IOERR it ignores, instead proceeding to try and use the data which was read. Sometimes this will cause an SQLITE_CORRUPT return - eg. if the last page is a btree interior page then zero-filling the end of the read buffer will almost certainly result in nonsense. But in the case of a leaf page the zero-filled buffer can still represent a "validly" formed database page and sqlite will proceed without reporting any error. Via this vector it is unfortunately possible for queries to return rows containing NULL in a column that is explicitly NOT NULL. I've mentioned this before: http://sqlite.1065341.n5.nabble.com/Null-returned-from-NOT-NULL-column-thanks-to-undetected-corruption-td93309.html I'm still not sure why sqlite ignores short reads; maybe something to do with creating databases (multi-process race when the file has been created but the first DB page hasn't been written yet?). Anyway this is the kind of detail most users don't care (or need to care) about. If you get _any_ kind of SQLITE_IOERR returned by sqlite it's best to assume your connection is hosed. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
