On 6/19/07, Andre du Plessis <[EMAIL PROTECTED]> wrote:
I had lots of problems here when starting with SQLite and painstaking I think I've figured it out.
Me too. You have sqlite3_prepare, which compiles the sql into byte code, then
Sqlite3_step to execute the query or update, if it is an update then there is no row, if query then call step until no more rows. Once done stepping you must either sqlite3_reset or sqlite3_finalize I believe that the finalize will do reset and free resources. Reset is designed to reuse the query or update.
Correct. I ended up writing a (multi-thread aware) C++ framework to keep me out of trouble. In the SQLite namespace I have class exception; class database; class connection; class statement; class execution; class query_result; where the ownership model is well-defined, and the data-use paths are protected from coding mistakes at compile time. There can be only one execution attached to a statement at any one time, and the query result is owned by the execution. When the execution terminates (goes out of scope), the statement is reset automatically. It is important though to reset (if you don't finalize) because if you
don't reset you may have an open lock on the table and this will lock out other processes and they will get a SQLITE_BUSY error, because depending on what the sql is doing, it may have a cursor which may lock the table.
Exactly the result I had. Since I am a strong believer in "prepare once, use many" for performance reasons, I ended up having to write my own framework to keep me out of trouble, and to reduce the amount of "busy work" around the "C" interface to sqlite. --a
