AFAIK The sqlite logging function already includes the OS error message for i/o errors, so you'll have it there in the log already. It would be difficult to capture that and plumb it back to the callsite though, since the logging function provides you with zero context as to which connection is responsible for its invocation (the callback is configured globally). Probably simpler to call sqlite3_file_control() to get the last error code and convert to the relevant message according to platform.
-Rowan On 10 May 2017 at 17:32, Philip Warner <p...@rhyme.com.au> wrote: > Interesting idea; when I've finished diagnosing my current problem, it > might be worth expanding the repertoire of the Android library. > > I presume that the sqlite logging function could be used to get the > message at least, is that correct? IIRC, it's called on an error and the OS > file-related errors are often still available, but I am very rusty on this > stuff. > > > On 8/05/2017 5:32 PM, Rowan Worth wrote: > >> Preserving the underlying cause is still possible to do portably; >> something >> like sqlite3_os_errmsg() would provide an "opaque" string suitable for >> user/developer consumption. >> > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
