如果你使用过sybase,ms sql server等关系数据库，你可能对interbase的事务处理感到奇怪。在interbase中如何进行事务处理呢？如何启动、提交、回退事务呢？ interbase中进行事务处理的语句在哪里呢？特别在编写和使用存储过程、触发器时，不少人存在这种疑惑。实际上，只要搞明白最关键的一点， interbase的事务处理就彻悟了，那就是：interbase不支持内嵌事务处理，根本不存在进行事务处理的语句。这也就是为什么 interbase的sql语言不和其他关系数据库一样称作T-SQL。你不可能像sybase等数据库一样，在存储过程和触发器中通过begin trans(action),commit trans(action),rollback trans(action)等语句进行事务处理。那么intebase的事务如何运作呢？在interbase中，所有的事务，不论是显式的还是隐式的，全部通过客户端启动，并根据客户端操作的情况要么提交要么回退。当客户端发起一个sql请求时，同时也启动一个事务，如果该语句执行成功， interbase就自动提交该事务；否则，如果该语句执行失败，interbase就回退事务。从这个意义上讲，能不能认为interbase的事务都是客户端事务而不是服务器端事务呢？否！一定要搞清楚，interbase的事务必然而且肯定是在服务器端由interbase数据库引擎操作管理的，只是interbase事务的启动是在客户端发起，而不是在服务器端发起，这是最本质的一点。一个sql语句的执行可能会嵌套调用或引发其他sql语句的执行，这些sql语句也会启动各自的事务，我们把第一个被启动的事务称为根事务，其他事务称作子事务。这样，根事务、子事务就形成了一个具有嵌套结构的事务链。只有当该事务链中所有环节对应的操作全部执行成功（不能有任何一个失败），interbase才提交事务；相反，只要事务链中任意一个环节对应的操作失败（尽管其它环节操作成功），interbase就回退全部事务。interbase决不会进行部分事务的提交。这就是interbase的事务运作机理，也即interbase强调的atomic transaction。

　　明白了这一点，让我们看一下interbase的存储过程和触发器的事务问题。存储过程是由客户端调用执行的，客户端执行存储过程的同时也启动了一个事务，不妨假定这个事务就是该存储过程的根事务，存储过程中的任何一条 sql语句都会启动相应的子事务，这些子事务嵌套在上述根事务中，形成一个事务链。根据前面的说明，不论是根事务对应的调用操作，还是子事务对应的存储过程中的操作，只要有一个操作失败，interbase就回退事务链中全部的事务，从而不对数据库造成任何实质的更改；只有当所有的操作全部执行成功， interbase才会提交事务链中所有的事务，对数据库进行实质性更改。
 
　　触发器是由于客户端执行插入、更改、删除等操作时激发的。客户端执行插入、更改、删除等操作时肯定会启动相应的事务，不妨假定为根事务，而由它们激发的触发器中的sql语句操作启动的子事务被嵌套上述的根事务中，从而也形成一个事务链。如果触发器中有某个语句执行失败，interbase就会回退所有事务，触发器的操作不会生效，激发它的插入或者更改或者删除等动作也被回退；同样，如果插入、更改或者删除等操作失败，整个事物也被回退，触发器同样也不起作用。只有当所有的操作全部执行成功，插入、更改、删除操作才生效，触发器也才起作用。

　　明白了上面的解释，你可能也就理解了在存储过程和触发器中没有事务操作语句的原因了。实质上，与其它数据库相比，interbase极大的简化了存储过程、触发器的编写。

　　顺便说明一下，如果你使用delphi的IBX编写客户端，你可以通过TIBTransaction的starttransaction,commit(或 commitretaining),rollback(或rollbackretaining)选择合适的时机明确地启动、提交、回退事务。但是，一定要遵守一个原则，即：事务期间要尽可能地短。