Hello Simon, Yes I am following that sequence. However I do my sqlite3_column(...) calls to extract data from selects between the step() and reset() calls.
My concern is the time between the step() and reset() calls if another select step() is attempted from another thread with a separate DB connection. I am afraid that the second step() call will fail with a "database locked" error since the first step() call is complete but the reset() has not taken place yet (because I am doing column() calls to extract the retrieved data before resetting the prepared statement). Thanks, John --- On Fri, 5/13/11, Simon Slavin <slav...@bigfraud.org> wrote: > From: Simon Slavin <slav...@bigfraud.org> > Subject: Re: [sqlite] Common Multi-treaded Problem > To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> > Date: Friday, May 13, 2011, 9:05 PM > > On 14 May 2011, at 12:29am, John Deal wrote: > > > I actually never finalize prepared statements until > the DB is closed and not being used anymore. I reset > the prepared statements. For writes (inserts, updates, > etc.) I use explicit transactions with commits (or rollbacks > if errors). I reuse the prepared statements by > rebinding parameters (always changing anyway). My > understanding is you finalize a prepared statement when you > know you will not use it anymore to free up resources. > My application uses the prepared statements until the DB is > shutdown. Is that not proper? Please enlighten > me if this is not what I should be doing. > > You may be okay, as long as you conform to the order in > > <http://www.sqlite.org/c3ref/stmt.html> > > "The life of a statement object goes something like this: > > • Create the object using > sqlite3_prepare_v2() or a related function. > • Bind values to host parameters using > the sqlite3_bind_*() interfaces. > • Run the SQL by calling > sqlite3_step() one or more times. > • Reset the statement using > sqlite3_reset() then go back to step 2. Do this zero or more > times. > • Destroy the object using > sqlite3_finalize()." > > So if you do a _reset() after the last _step() for each > search, which is what you say you do, you should be > okay. Then do a _finalize() before closing the > database handle. > > I still think it should be possible to find out where your > leak is, though I'm not sure how. I would recommend > that you check the result code for every call to a sqlite3_ > function, though, if you're not already doing that. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users