3d建模软件有哪些南昌seo
语法
BEGIN TRANSACTION;
COMMIT TRANSACTION; （或END TRANSACTION;）
ROLLBACK TRANSACTION;
事务处理
除了一些PRAGMA语句以外，其它访问数据库的语句会自动启动事务处理，并且在结束时自动提交。
通过上一节的命令可以手动控制事务处理过程。
如果在事务期间关闭了数据库，或者发生了错误并且通过ON CONFLICT指定了冲突处理算法，则会自动回滚事务。
事务控制语句不能嵌套执行，可以通过SAVEPOINT和RELEASE命令模拟嵌套行为。
通过SAVEPOINT在事务中创建保存点，回滚时指定保存点名称可回滚到指定位置，之前的处理将保存。
读事务和写事务
SQLite支持多个数据库在不同线程或进程同时读，但只支持一个写事务存在。
读事务只能读数据，写事务可以读也可以写。通过SELECT可以启动一个读事务，CREATE，DELETE，DROP和UPDATE启动写事务。在一个读事务期间如果出现写操作，事务会升级为写事务。但如果此时有另一个数据库连接正在处理写事务，上一个写操作就会失败并报告SQLITE_BUSY错误。
当一个读事务活动时，另一个连接对相同表的写操作不会反馈到读事务中，也就是说不会读到写操作刚刚写入的数据。
DEFERRED, IMMEDIATE和EXCLUSIVE事务
DEFERRED是默认行为，表示在访问数据库之前事务并未真正启动，仅仅是设置一个标记告诉数据库关闭自动提交功能。事务会在显式调用COMMIT或ROLLBACK或发生错误时自动回滚执行以重新启用自动提交操作。
DEFERRED启动后，如果第一个语句时SELECT，则启动一个读事务。后续出现写操作时自动升级为写事务。
IMMEDIATE语句则是告诉数据库立即启动一个写事务，并不会通过下一条语句是读还是写来确定事务类型。如果此时另一个连接已启动了一个写事务，则该操作失败并报告SQLITE_BUSY错误。
EXCLUSIVE与IMMEDIATE类似，在WAL mode格式下是完全相同的，但在其它日志模式下该语句会阻止其它连接读取数据库。
隐式事务和显式事务
隐式事务（不是通过BEGIN启动的事务）在语句完成后自动提交事务。当一条语句reset或finalized时，其打开的游标自动关闭，标识着语句完成。有些语句可能因为事务控制原因在reset或finalized之前完成，但这一行为无法保证，所以不要假定在reset或finalized之前语句已结束。可以保证的是调用sqlite3_reset或sqlite3_finalize之后语句一定是完成状态。sqlite3_blob在启动增加BLOB读写期间，只有在明确关闭blob时才表示语句完成。
COMMIT命令会立即执行提交操作，即便有SELECT语句尚未完成也没关系，但如果有写操作未完成则会报SQLITE_BUSY错误。
这应该是发生在事务有多线程处理的情况。
如果有另一个线程或进程有读操作，COMMIT操作可能报告SQLITE_BUSY错误，此时可以等待那个读操作完成后再次尝试COMMIT。
早期版本中(3.7.11之前）ROLLBACK可能因存在未完成的查询操作而报告SQLITE_BUSY错误。之后的版本遇到这一行为时不会报错，但会撤销未完成的查询操作，并导致那些操作返回SQLITE_ABORT错误或SQLITE_ABORT_ROLLBACK错误。在3.8.8及之后的版本中，只要回滚操作不修改表结构，未完成的读操作将继续处理而不受ROLLBACK影响。
如果PRAGMA_journal_mode设置为OFF（关闭回滚日志），ROLLBACK的行为不确定。
事务出错处理
有些错误不会导致事务回滚，以下错误会导致自动回滚：
- SQLITE_FULL: 磁盘空间不足
- SQLITE_IOERR: 磁盘IO错误
- SQLITE_BUSY: 数据库正在被其它进程使用
- SQLITE_NOMEM: 内存不足
对于这些错误，SQLite尝试回滚刚才发生错误的操作，而事务内之前完成的操作则保持不变，并且继续执行事务内的其它操作。但是通常我们会希望回滚事务内的所有操作以确保数据的一致性，通过C语言接口sqlite3_get_autocommit可以检查SQLite是采取了单个回滚还是全部回滚行为。
建议在应用程序内拦截这些错误以显式调用ROLLBACK命令回滚整个事务。如果SQLite本身已回滚了下个事务，再调用ROLLBACK会报错，但这个错误无关紧要，可以忽略。
后期版本可能会增加其它导致事务自动回滚的错误清单，也可能改变对不同错误的回滚行为，特别是针对这些错误简化回滚行为。
原文链接：https://www.sqlite.org/lang_transaction.html