On 5 Sep 2014, at 1:58pm, Jan Slodicka <[email protected]> wrote: > 1) SQLITE_OK should not happen. (Official documentation allows /ANY/ result > code. I hope this not true.) > 2) If it happens, then this looks dangerous.
You are correct. If you use this routine only for SELECT commands or PRAGMAs which return results, SQLITE_OK should never happen. You might get SQLITE_OK from a command that makes a change (e.g. INSERT, or a PRAGMA which changes things). > I don't like a lot of things about the C# wrapper (heavy overhead, > SQL_SCHEMA dealing, timeouts...). But those points are not crucial. What I > ask is following: > > a) If sqlite3_step() returns error code different from 100/101, should we > call sqlite3_reset()? This looks like a bug to me. (Imagine we are reading a > table.) The statement is still valid, it just can't be used right now. So you might want to use it later. However, the only reason for wanting to call sqlite3_reset() is if you might want to execute the same command later. Since this is a wrapper it seems unlikely that you would want to do this in your situation. Instead, it is more likely that you would want to call sqlite3_finalize(). You would do this to tell SQLite that you are finished with the statement and want to release its memory and other resources. > b) If we get Locked/Busy errors, is it safe and reasonable to retry > sqlite3_step? Note that if we solve this way some multi-access conflicts, > then this is a welcome feature. It is probably not appropriate to retry sqlite3_step(). If the database was locked past whatever timeout you set, it will still be locked. If it was busy it will still be busy. The normal thing to do if you very Locked/Busy is to issue some kind of error message to the user. In your situation you'd probably have that routine do something similar to what it would do for a badly formatted command. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
