Re: [sqlite] Transaction behaviour

> SQLite transaction is a property of a database connection - there ain't > no such thing as a transaction spanning multiple connections. In hindsight, I completely overlooked that very point. Between then and now it's all been refactored to do this correctly. Thanks everybody! jlc

Re: [sqlite] Transaction behaviour

On 1/23/2014 5:12 PM, Joseph L. Casale wrote: The bulk load doesn't have to be done this way, only one process loads data and even a single connection can be used but that would segment the wrapper. SQLite transaction is a property of a database connection - there ain't no such thing as a

Re: [sqlite] Transaction behaviour

> Start the bulk load with "BEGIN IMMEDIATE;" or "BEGIN > EXCLUSIVE;" and count errors. > If there were no errors at the end of the bulk load, issue > "COMMIT;", else issue "ROLLBACK". > If the program crashes, sqlite will take care of the rollback > automatically the next time any process opens

Re: [sqlite] Transaction behaviour

On Thu, 23 Jan 2014 16:30:57 +, "Joseph L. Casale" wrote: >I have a scenario where I am writing a series of entries across several tables >with relationships using Python and context managers. The sql is abstracted >away from the user by a class providing all the

Re: [sqlite] Transaction behaviour

On 1/23/2014 11:30 AM, Joseph L. Casale wrote: is there anything about transactions I am not seeing where I can accomplish leaving the bulk load uncommitted in the event of an issue in my case? I'm not sure I understand the nature of the difficulty. If you don't want to COMMIT a transaction,

[sqlite] Transaction behaviour

I have a scenario where I am writing a series of entries across several tables with relationships using Python and context managers. The sql is abstracted away from the user by a class providing all the needed methods. These each open implicit transactions, now its been asked that during the bulk