On 10 Sep 2011, at 4:22pm, Steffen Mangold wrote: > http://www.sqlite.org/lang_transaction.html > " Such transactions usually persist until the next COMMIT or ROLLBACK > command. > But a transaction will also ROLLBACK if the database is closed or if an error > occurs and the ROLLBACK conflict resolution algorithm is specified. > See the documentation on the ON CONFLICT clause for additional information > about the ROLLBACK conflict resolution algorithm."
Okay, so that one depends on what you've specified for ON CONFLICT. Fair enough. > http://www.sqlite.org/lang_conflict.html > " ABORT - When an applicable constraint violation occurs, the ABORT > resolution algorithm aborts the current SQL statement with an > SQLITE_CONSTRAIT error and backs out any changes made by the current SQL > statement; > but changes caused by prior SQL statements within the same transaction are > preserved and the transaction remains active. This is the default behavior > and the behavior proscribed the SQL standard." Ah. I misunderstood. ABORT is not an error. So your problem from your earlier post is this: > In this example I added 10 objects to the context and I know that object #5 > raises a PrimaryKey (or unique) Exception. > What I read from the SQLite documentation I understand that object #6 till > object #10 will be also add to the database. > But this never happens. I assume you mean that you do eventually do a COMMIT. So what's happening is that ABORT not only aborts the current operation but also aborts all other operations until you do either a COMMIT or a ROLLBACK. Which is interesting. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
