The doc page for SQLITE_BUSY covers SQLITE_BUSY when there are multiple
connections to the database.
SQLite Result Codes (SQLITE_BUSY)
http://www.sqlite.org/rescode.html#busy
But, I have only one connection. I believe the case where SQLITE_BUSY is
returned by sqlite_close() due to unfinalized prepared statements should be
mentioned there.
Jeff
> On Aug 21, 2015, at 3:51 AM, R.Smith <rsmith at rsweb.co.za> wrote:
>
> Hi Jeff,
>
> On 2015-08-21 07:30 AM, Jeff M wrote:
>> Sometimes my iOS app creates an unreasonable number of prepared statements
>> (perhaps 1,000, an app bug that I'm fixing). These prepared statements are
>> later finalized just prior to doing sqlite3_close(), which sometimes returns
>> SQL_BUSY. The docs say SQL_BUSY will be returned if I haven't finalized all
>> prepared statements, but I believe I have done so. My iOS app has only one
>> connection to the DB and I'm doing all this work on the main thread.
>>
>> 1. The docs don't say what to do in the case of SQL_BUSY. Does that mean
>> I've certainly failed to finalize one or more prepared statements, or does
>> SQLite just need more time (in which case can I loop on sqlite3_close()
>> until I get SQLITE_OK)?
>
> SQL_BUSY does not mean anything bad except that you are trying to do some
> work on a query (read: prepared statement) while another is still not done
> with its duties. These duties may in your case simply mean that the "closing"
> of a previous prepared statement is still under way, so yes, it just needs a
> moment. You can wait a moment and try again.
>
> I will mention (as Simon is likely to point out soon!) that the good news is:
> SQLite will do this waiting-and-retrying for you if you simply set a suitable
> time-out, perhaps in the order of a minute or more, using the pragma:
>
> http://www.sqlite.org/pragma.html#pragma_busy_timeout
>
> or, if you prefer using the C-interface:
> http://www.sqlite.org/c3ref/busy_timeout.html
>
