> 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 the database. > > http://sqlite.org/c3ref/get_autocommit.html can help you decide > what mode you are in. > > By the way, autocommit is not the best thing to do if you have > related insert/update/delete statements in an application > transaction. Related updates should be in the same, atomic, > transaction.
Hi Kees and Igor, I appreciate the atomic violation of the current implementation. The issue lies in the fact the individual rows for each table consume a cursor and are wrapped in a context manager which starts its own transaction. The wrapper that abstracts the user from raw sql, connections and cursors hands out individual connections as the data's consuming access is multiprocess based and to work around the concurrency issues I have no choice. 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. So either that or temp tables / other schema changes might be needed in this case. I'm looking at refactoring properly for the sake of correctness. Thanks, jlc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
