> Pavel, could you please specify what do you mean by "statements in this 
> transaction"? Statements
> that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the 
> transaction?

Statements that were initiated during the transaction.

> Also, is this something that one should immediately deduce, necessary 
> behavior based on the model
> of SQLite (or perhaps RDBMS, ACID), or is it something that one normally 
> learns by heart, being,
> for the end-user, just the way SQLite works?

Basic model for any transaction-based DBMS that support any
transaction isolation level stricter than "read uncommitted":
obtaining data for select statement cannot cross transaction boundary,
otherwise data would be inconsistent. But different DBMS can treat
this rule differently. SQLite fails to execute COMMIT if some
statements are active, Oracle cancels execution of all active
statements while executing COMMIT I believe. So it's some specifics
which should be learned by heart if one wants to work with DBMS
seriously.


Pavel


On Thu, May 12, 2011 at 9:53 PM, Mihai Militaru <mihai.milit...@xmpp.ro> wrote:
> If you don't mind, John, for bullying in the discussion...
>
> On Thu, 12 May 2011 17:58:40 -0400
> Pavel Ivanov <paiva...@gmail.com> wrote:
>
>> There's no dependency between different prepared statements, but there
>> is dependency between transactions as they use the same database. And
>> transaction cannot be finished (implicitly or explicitly) until all
>> statements in this transaction are reset or finalized.
>
> Pavel, could you please specify what do you mean by "statements in this 
> transaction"? Statements
> that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the 
> transaction?
>
> Also, is this something that one should immediately deduce, necessary 
> behavior based on the model
> of SQLite (or perhaps RDBMS, ACID), or is it something that one normally 
> learns by heart, being,
> for the end-user, just the way SQLite works?
>
> Thanks,
> Mihai
>
> --
> Mihai Militaru <mihai.milit...@xmpp.ro>
> _______________________________________________
> 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

Reply via email to