I think I see.

Everything the transaction does (forward and backward) stays invisible until the TIP indicates the
transaction has committed. If a statement fails half-way through, Firebird first attempts to undo
the changes of that statement (only) via an undo log. If that succeeds, then it tells the user the
statement failed, but keeps the transaction moving forward; the statement appears undone and
everything's fine. If for some reason it fails to undo the statement's changes, it can always throw
an error and kill the transaction. Either the statement gets rolled back, or the transaction gets
rolled back, but it's safe regardless. Sweet!

Ann, Helen, thanks!

-Philip

---------- Original Message -----------
From: "Ann W. Harrison" <aharrison@...>

> The SQL Standard dictates that update, insert, and delete statements
> that affect multiple rows, procedures, and triggers are all "atomic" -
> all changes succeed or fail. Firebird meets that requirement by keeping
> a undo log - a list of records affected by the statement with the
> information necessary to undo the action if the statement (or procedure
> or trigger) fails. The same mechanism also handles rolling back to a
> savepoint. And yes, there can be several different levels of undo log
> and the mechanism handles cases where the same record is changed many
> times at different levels in nested operations.
>
> Regards,
>
> Ann

------- End of Original Message -------