> Currently SQLITE_ERROR stands for two very different errors:
> > #define SQLITE_ERROR 1 /* SQL error or missing database */
> It would make sense to have separate codes for them to avoid possible confusion, because these two errors really have nothing in common.
I note that the "extended result code" feature is relevent:
Re: SQLITE_ERROR ("SQL error or missing database") should be split into two codes: "SQL error" and "missing database"
On 07/07/2017 12:04, Simon Slavin wrote:
> I note that the "extended result code" feature is relevent:
> You’re proposing two error codes like
> for a missing database file, and for one which has the wrong text in the magic header area.
> I’d suggest some of my own:
> Does anyone want to contribute others ?
There are some other problems in error definitions. For example, what
does SQLITE_FULL mean? How can database be full? Is it really a
> #define SQLITE_FULL 13 /* Insertion failed because database
is full */
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.
> 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
> > #define SQLITE_FULL 13 /* Insertion failed because database is
> full */
Disk is full, or the database cannot hold more pages, or a table cannot
hold more rows (because all ROWIDs have been used).
> 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
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: