On 21 Sep 2015, at 8:29am, Rowan Worth <rowanw at dugeo.com> wrote: > 1) Statement is prepared > 2) Statement is stepped > 3) Statement is reset > 4) ... time passes ... > 5) Statement is stepped > 6) Statement is reset > 7) ... time passes ... > etc. etc. > > The assertion seems to be that if the return value of sqlite3_column_count > is cached at step 2 it will still be valid at step 5
Sorry, no. I was saying that if it was cached at step 2 it will still be valid until the end of step 3. And that if cached at step 5 it will still be valid until the end of step 6. My understanding is that the database is locked by the first call to _step() and unlocked at the first of ... (A) _step() returns SQLITE_DONE (B) _reset() is called (C) _finalize() is called As long as you check the column-count at your first call to _step() then you're fine until one of the above happens. If that worries you, put your SELECT command in a transaction. That means no changes can happen until the transaction finishes no matter how many times _reset() is called. That's what I did in my test. Another solution is not to use "SELECT *" but instead to specify the values you want returned. That way you know how many (and which) columns will be returned because it'll be the number of columns that was requested in your SELECT. It'll work or it will result in an error, but there's no way it can return the wrong number of columns. Simon.
