Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / March 2006

Tip: Looking for answers? Try searching our database.

Bug (?) in SQL: Global temporary table gets truncated on failed insert.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
fintudet@datatech.ru - 16 Feb 2006 13:54 GMT
Hello.

During some experimentation with DB2 decimal numbers representations, I
have discovered very unexpected  behaviour of the global temporary
table. Consider this example.
Such I had executed the example: # db2 -td@ -f FILENAME.

When an single Insert into table fails, the table gets empty. Could
anybody shed some light on this ?

----( code )----------------------
   DECLARE GLOBAL TEMPORARY TABLE #r
   (
        res decimal(31) not null
    )
       ON COMMIT  PRESERVE  ROWS
       NOT LOGGED
@
   insert into session.#r values( 1 ) @
   insert into session.#r values( 2 ) @
   insert into session.#r values( 3 ) @

   select * from session.#r
-- here is expected result: 3 rows with consecutive values : 1,2,3
@
BEGIN ATOMIC
   declare m_fact decimal(15) default 1;

   FOR X AS
       select
              m_fact * 9999999999999999999999999999999. +
.0000000000000000000000000000001 as val
       from sysibm.sysdummy1
   DO
-- next line FIRES THE ERROR: SQL0802N
       insert into session.#r values( X.val );
   END FOR;
END
@
   select * from session.#r
-- HERE the table "session.#r" is empty: 0 rows returned. WHY ?
@
kanda - 16 Feb 2006 14:34 GMT
Sorry, I forgot to mention my system:
IBM DB2, Enterprise Server Edition, 8.1.6 @ MS Windows Server 2003 @
Intel x32.
Serge Rielau - 16 Feb 2006 15:00 GMT
> Sorry, I forgot to mention my system:
> IBM DB2, Enterprise Server Edition, 8.1.6 @ MS Windows Server 2003 @
> Intel x32.

This is working as designed for NOT LOGGED temporary tables.
http://publib.boulder.ibm.com/infocenter/db2luw/v8//index.jsp
"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."

If an UPDATE/DELETE or INSERT operation against a temp table fails in
mid flight DB2 has to roll back the SQL statement to comply with the
"Atomic" in ACID.
Since the change was not logged there is no way to comply with
Atomicity. So three choices remain:
1) drop the table (mark the table as unusable as doen for regular tables
when NOT LOGGED operations fail)
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.

Cheers
Serge
Signature

Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Konstantin Andreev - 17 Feb 2006 12:02 GMT
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. The other glaring case is the way for exporting data from
DB2 to a text file.

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 :(

> 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).

*   Rule of Least Surprise: always do the least surprising thing. (This
is also widely known as the Principle of Least Astonishment.) -- Eric
S.Raymond.

   The disappearance of the innocent rows is very surprising thing.

*   Since it's user responsibility for declaring "NOT LOGGED", don't
deprive him the freedom to recover the error himself, according his
current needs. If DB2 would implement (3) then user could drop table,
delete rows himself, or work further, if applicable.

   This is another good principle: "Supply mechanism, not policy."
--
Konstantin Andreev.
Serge Rielau - 17 Feb 2006 13:52 GMT
> 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.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.