At 02:44 AM 11/09/2005 -0700, you wrote:

>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?

The changes "so far" are in new record versions and the originals of the
rows updated are in deltas.

>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 yet. Your transaction continues to see whatever is visible to it, its
own updates included. The magic starts happening when you roll back the
transaction (or fix the problem and continue....depends on your application
code....) The data from the deltas of rolled back updates reverts to being
the newest record versions of all of the rolled-back updates and those new
record versions will become eligible for cleanup.

./heLen