Hello. In our embedded system we have two databases ATTACHed to each other and size constrained with max_page pragmas directed at each. (Different filesystems: one is on a tmpfs in RAM, the other on JFFS).
When I perform an sqlite3_exec() to DELETE too many rows in the secondary ATTACHed database and a disk or database full error occurs, I properly get a code 13 returned from the API. But if I then turn around and call sqlite3_errmsg() I get "not an error" returned. (Our too-complicated custom sqlite wrapper does this.) Guesses: The error string returned by sqlite3_errmsg() comes from the connection structure, and it says "not an error" because, indeed, there as no error on the primary DB. There is a hidden handle/structure for the ATTACHed DB that has the correct error string, but sqlite3_errmsg() does not look there. If I passed in an error string pointer to the exec() call itself, I would properly get a "disk or database full" message. In fact, that may be one of the reasons such a parameter exists on this API. The rule is, if it is an exec(), get your error string from the exec() call, otherwise, you can get it from sqlite3_errmsg(). (This is no big deal as it is just for our internal logging, and, obviously I am being lazy by not just running a test in the shell to see, and, also, our wrapper code is likely buggy and is also obscuring what I am really doing even from myself (!), but thought it worth throwing this out for others and to be sure my conceptual model was not too far off the mark before I start hacking away.) Thanks again. -- Ward _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
