Thank you very much for the skilled answer. The question is taken off,
but I eager to make some philosophic comments.
> This is working as designed for NOT LOGGED temporary tables.
> "When a rollback operation terminates a unit of work or a savepoint in
> P, and that unit of work or savepoint includes a modification to
> SESSION.T, then if NOT LOGGED was specified, the rollback includes the
> operation DELETE from SESSION.T, else the changes to T are undone."
> I realize now. IMHO, the biggest trouble with IBM (from the user's
> point of view) it makes things much more arduous then they could be. In
> this particular case it's DB2 documentation, which could be less
> intricate.
There is room for improvement in this paragraph, agred.
> The other glaring case is the way for exporting data from
> DB2 to a text file.
You are a tease! Spit it out man, what about it? :-)
> Historically, the most successful attempt of IBM to make the simple
> thing hard was "Job Control Language" for the early IBM mainfraims
> (like IBM/360). People worked with JCL are wincing at the mention of :(
Is late birth on my behalf a valid excuse?
>>Since the change was not logged there is no way to comply with
>>Atomicity. So three choices remain:
[quoted text clipped - 5 lines]
>>
>>Option 2) is deemed the most appropriate.
> This decision could be contested. You could consider next arguments
> against (2), but for (3).
[quoted text clipped - 10 lines]
>
> This is another good principle: "Supply mechanism, not policy."
Just like people will wear seatbelts and helmet if you just offer them.
This is a phylosophical debate indeed. It's like C vs Java.
Do you do error checks after each SQL statement?
Most(!) developers don't. Look at any procedure migrated from TSQL.
If DB2 deletes the table content on error you are bound to find out.
If it does not and their is not error test the app can silently fail,
wrong bank transactions, reservation, accounting....
For an industrial strength DBMS this is simply not acceptable.
There is a difference between what is consumable by the masses and what
is required for the high end.
Cheers
Serge

Signature
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Konstantin Andreev - 03 Mar 2006 12:10 GMT
> > The other glaring case is the way for exporting data from DB2 to a text file.
> You are a tease! Spit it out man, what about it? :-)
Hm... I've spent some time, trying to reproduce something about it now,
but failed. Sorry, It seems I was mistaken.
[ ... skip ... ]
> >>2) go to the only well defined state: emtpy
> >>3) leave the table in whatever state it is with an unknown amount of the changes done.
> >>Option 2) is deemed the most appropriate.
> > You could consider next arguments against (2), but for (3).
> >
> > * Rule of Least Surprise: always do the least surprising thing. ...
> > The disappearance of the innocent rows is very surprising thing.
> > * Supply mechanism, not policy. ... don't deprive the freedom to recover the error himself
> Do you do error checks after each SQL statement?
> Most(!) developers don't. Look at any procedure migrated from TSQL.
> If DB2 deletes the table content on error you are bound to find out.
> If it does not and their is not error test the app can silently fail,
> wrong bank transactions, reservation, accounting...
Sure, this is very strong argue. The approach that ensures less errors
is preferable. Thank you for cognitive discussion.
--
Konstantin Andreev.