T
Tim Kuehn
Guest
[quote user="Mike Fechner"] The problem is, that a developer reading only that internal procedure may assume that when the ASSIGN failes, the CREATE is undone. But it won't. Code should be easy to understand. [/quote] Are we projecting something here? I personally don't assume anything about follow-on developers so I try to communicate intent as often as possible. My personal opinion on TRANSACTION blocks is that it says "this all gets grouped together". If a failure happens with CREATE - or any other place - the result will be a business logic issue that needs to be fixed regardless of whether the entire TX was backed out or only parts of it. And I have seen cases in a TX block where the code ran into an runtime issue where part of the work was left undone w/out triggering the UNDO behavior, so a DO TRANSACTION isn't a 100% all-or-nothing guarantee.
Continue reading...
Continue reading...