On Tue, Oct 8, 2013 at 8:01 PM, Dan Kennedy <danielk1...@gmail.com> wrote:

> On 10/08/2013 07:39 PM, Clemens Ladisch wrote:
>
>> Paul Harris wrote:
>>
>>> Many years ago, Igor mentioned that you should always reset/finalize any
>>> prepared statements before calling COMMIT.
>>>
>>> I am wondering, is this still true?
>>>
>> Yes.
>>
>

A related note from a recent conversation on the Fossil SCM mailing list
(link to the original post not included because the archives are only
visible to list members):


On Fri, Aug 16, 2013 at 7:29 PM, Richard Hipp <d...@sqlite.org> wrote:

> On Fri, Aug 16, 2013 at 1:26 PM, Stephan Beal <sgb...@googlemail.com>
>  wrote:
>
>> Hi again,
>>
>> db.pAllStmt and db_static_prepare() - i've ported/implemented that to
>> work at the db-connection level, but i have a question about this
>> particular implementation detail:
>>
>> void db_end_transaction(int rollbackFlag){
>>  ...
>>    while( db.pAllStmt ){
>>       db_finalize(db.pAllStmt);
>>     }
>> ...
>> }
>>
>>
>> Is there a technical reason which cached statements need to be cleaned up
>> in the commit/rollback or was that just a matter of taste/memory usage/etc?
>> i ask because i'm currently keeping mine open as long as the db connection
>> is alive and don't want to stumble into on a hard-to-track bug if there is
>> a reason the handles _must_ (for correct behaviour) be finalized as part of
>> the commit process.
>>
>
> There used to be.  When I wrote that code, SQLite required all prepared
> statements to be reset or finalized before a transaction would commit or
> rollback.  SQLite has since relaxed that requirement, however.
>
>

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to