On Sep 26, 2017, at 3:11 PM, Simon Slavin <[email protected]> wrote:
> On 26 Sep 2017, at 10:53pm, Guy Harris <[email protected]> wrote: >> >> I *would* suggests an additional API to get a *separate* extended error >> code, so that if, for example, a write() fails and that failure is turned >> into SQLITE_IOERR, you can get something that distinguishes EIO from other >> errors such as EFBIG, EDQUOT, etc.. > > You know about this, right ? > > <https://www.sqlite.org/c3ref/extended_result_codes.html> > > <https://www.sqlite.org/c3ref/c_abort_rollback.html> Yes. I do. You know about this, right? https://www.sqlite.org/rescode.html#ioerr_access It shows a whole bunch of codes, none of which are "something that distinguishes EIO from other errors such as EFBIG, EDQUOT, etc.". I'm not asking for something that indicates what xXYZZY method reported the error. I'm asking for something that indicates what the underlying problem causing the I/O error is, to the extent that information is available from the OS, i.e. *why* did the I/O operation not succeed? _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
