Subject | implementation questions -- how does firebird rollback a partially-executed statement? |
---|---|
Author | unordained |
Post date | 2005-09-11T09:44:10Z |
If I do something like
update table_a set field_a = cast(field_b as timestamp);
where *most* rows have field_b being a valid timestamp (say, stored in a varchar) but a few don't,
such that cast() will fail eventually, how does firebird go about ignoring its changes "so far"
when it spits out a conversion error?
It doesn't rollback the transaction, and the transaction (after the error) is unable to see the
partial changes, right? But the TIP only stores state for entire transactions, not statements ...
it would have been going around creating new record versions, pointing old record versions to new
ones, right up until it hit the error. There's magic going on here somewhere ...
(Not really a support question, I know. I just don't want to bug the dev- or arch- lists about it.
I should just grab the source and start hunting ...)
-Philip
update table_a set field_a = cast(field_b as timestamp);
where *most* rows have field_b being a valid timestamp (say, stored in a varchar) but a few don't,
such that cast() will fail eventually, how does firebird go about ignoring its changes "so far"
when it spits out a conversion error?
It doesn't rollback the transaction, and the transaction (after the error) is unable to see the
partial changes, right? But the TIP only stores state for entire transactions, not statements ...
it would have been going around creating new record versions, pointing old record versions to new
ones, right up until it hit the error. There's magic going on here somewhere ...
(Not really a support question, I know. I just don't want to bug the dev- or arch- lists about it.
I should just grab the source and start hunting ...)
-Philip