Hello, I'm sorry I have to bother you readers but I haven't understood http://sqlite.org/lockingv3.html chapter 7.
1. "In autocommit mode, all changes to the database are committed as soon as all operations associated with the current database connection complete." How does SQLite know when ALL operations … complete? In PERL DBI context, I may prepare and execute as many statements as I like. When does SQLite commit? 2. "The SQL command "COMMIT" does not actually commit the changes to disk. It just turns autocommit back on." Is AutoCommit enabled after every commit? Do I have to disable AutoCommit again after a commit to have it be disabled? 3. "If the SQL COMMIT command turns autocommit on and the autocommit logic then tries to commit change but fails because some other process is holding a SHARED lock, then autocommit is turned back off automatically. This allows the user to retry the COMMIT at a later time after the SHARED lock has had an opportunity to clear." If I had AutoCommit disabled and the commit fails, I have to retry to commit myself. Is it possible (AutoCommit enabled or disabled) to have commits get queued and executed when possible by SQLite so that I don't have to write code myself but can rely on the order of commits (per connection)? 4. "By default, SQLite version 3 operates in autocommit mode." Is SQLite transactional by default? Do I have to use transactions? I'd like to. Anything besides begin and commit I have to consider? 5. Does a "SELECT …" require a transaction begin and commit to transfer data? Thank you! Lars Hansen _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
