On 23 Jul 2014, at 8:56pm, Mayank Kumar (mayankum) <mayan...@cisco.com> wrote:
> I have already enabled extended error codes but I am not seeing any extended > error codes being returned. I also enabled the error logging callback which > just prints the errorcode and the error message which I was already getting > when the sqlite3 api was failing. If you have enabled extended error codes you should be getting extended error codes returned by the API calls themselves. I'm afraid that is all you can get. > I know this error logging callback can report misuse of api's etc, but can > this facility or any other logging facility tell me more about why an api is > failing like for .e.g. in some customer scenarios I get sqlite_busy or > database is locked and I am trying to add the error logging callback to see > if I can get more details on why the database is locked or which process has > locked it, etc. Sorry, SQLite does not know what process has the database locked. The processed do not have codes, and no code is stored then the database is locked, just the fact that a process wants it to be locked. > I have only one process which opens a connection to the database and > sometimes when it restarts and then it detects the database is locked > although there is no other process which accesses it. Do you call have a timeout value set before you make the API call which opens the database ? Your description suggests that your process is not unlocking the database correctly when it quits to restart. Is that process quitting under its own control, or is it crashing ? If it is quitting under its own control is should be calling sqlite3_close_v2() and then sqlite3_shutdown() and checking the responses to make sure it was correctly able to release all resources. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
