dbTalk Databases Forums  

DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!?

comp.databases.ibm-db2 comp.databases.ibm-db2


Discuss DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!? in the comp.databases.ibm-db2 forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
fikko
 
Posts: n/a

Default DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!? - 03-09-2012 , 09:24 AM






Hello,
I execute a very simple load in INSERT mode, first run, all rows inserted:
Number of rows read = 100
Number of rows skipped = 0
Number of rows loaded = 100
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 100

next run:

Number of rows read = 100
Number of rows skipped = 0
Number of rows loaded = 100
Number of rows rejected = 0
Number of rows deleted = 100 <--- WHY ?
Number of rows committed = 100

It seems that same records are overwritten (the table has a PK) !
Follow my load script:

LOAD FROM TABLE.DAT
OF ASC
MODIFIED BY STRIPTBLANKS USEDEFAULTS DATEFORMAT=\"YYYY-MM-DD\"
METHOD L
(
1 5,
6 21,
22 39
)
MESSAGES TABLE.LOG
INSERT INTO TABLE
(
C1,
C2,
C3
)
NONRECOVERABLE
INDEXING MODE AUTOSELECT

I would like to get an exception for duplicate key values,
Thanks in advance and regards

--- Posted via news://freenews.netfront.net/ - Complaints to news (AT) netfront (DOT) net ---

Reply With Quote
  #2  
Old   
fikko
 
Posts: n/a

Default Re: DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!? - 03-09-2012 , 09:29 AM






Il 09/03/2012 16:24, fikko ha scritto:
Quote:
ODE AUTOSELECT

I would like to get an exception for duplicate key values,
Thanks in advance and regards

--- Poste
maybe full log could help:

SQL3501W The table space(s) in which the table resides will not be
placed in
backup pending state since forward recovery is disabled for the database.

SQL3109N The utility is beginning to load data from file
"TABLE.DAT".

SQL3500W The utility is beginning the "LOAD" phase at time "03/09/2012
16:25:42.303822".

SQL3519W Begin Load Consistency Point. Input record count = "0".

SQL3520W Load Consistency Point was successful.

SQL3110N The utility has completed processing. "100" rows were read
from the
input file.

SQL3519W Begin Load Consistency Point. Input record count = "100".

SQL3520W Load Consistency Point was successful.

SQL3515W The utility has finished the "LOAD" phase at time "03/09/2012
16:25:42.403906".

SQL3500W The utility is beginning the "BUILD" phase at time "03/09/2012
16:25:42.404093".

SQL3213I The indexing mode is "REBUILD".

SQL3515W The utility has finished the "BUILD" phase at time "03/09/2012
16:25:42.754445".

SQL3500W The utility is beginning the "DELETE" phase at time "03/09/2012
16:25:42.781363".

SQL3509W The utility has deleted "100" rows from the table.

SQL3515W The utility has finished the "DELETE" phase at time "03/09/2012
16:25:42.871074".


Number of rows read = 100
Number of rows skipped = 0
Number of rows loaded = 100
Number of rows rejected = 0
Number of rows deleted = 100
Number of rows committed = 100


--- Posted via news://freenews.netfront.net/ - Complaints to news (AT) netfront (DOT) net ---

Reply With Quote
  #3  
Old   
mor
 
Posts: n/a

Default Re: DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!? - 03-09-2012 , 09:30 AM



You could specify a WARNINGCOUNT value (e.g 1) to stop the load on
any warnings.
You could specify a FOR EXCEPTION clause to cause load to write
exceptions to a different table.
You are using 'insert into' which means "add data without changing
existing".

Reply With Quote
  #4  
Old   
Mark A
 
Posts: n/a

Default Re: DB2 LUW 9.7 FP5 LOAD - wrong default behaviour ?!? - 03-09-2012 , 10:43 AM



On Fri, 09 Mar 2012 16:24:00 +0100, fikko wrote:
Quote:
I would like to get an exception for duplicate key values, Thanks in
advance and regards
Not sure what you want since the duplicate rows were removed. You can try a IMPORT instead of
LOAD, which checks the rows as they are being inserting for any constraint violations. The LOAD utility
does not check the constraints until after all the data is loaded, becasue it is much faster that way.

As already mentioned by mor, you can use a discard table to show which rows got deleted when
checking constraints. See the manual.

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.