Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 18 Jun 2003 @ 20:56:10 GMT


     
  <Prev Next>  
<<First
<Prev
Next> Last>>  


Subj:   MultiLoad oddity, possibly a bug
 
From:   John Adams

We had a confusing error turn up yesterday, and it took me a minute to get it right.

A MultiLoad job ran with one row rejected and logged into the UV table. It was a small file--94 rows--so I looked manually for uniqueness violations using sophisticated UNIX analysis tools such as cut, sort, and uniq. There weren't any, no matter how often I looked.

I got into the UV table and noted the rejected row so I could look at the table for possible uniqueness violations. (This shouldn't be possible, as the load date wasn't in the table yet for this monthly load, but I was being cautious.)

Finally, I glanced at the DBCErrorCode field, expecting to see a 2801 or something like that.

Instead, it was a 2617--integer overflow (business must be good!)

So, what's the deal--why did a 2617 overflow go into the uniqueness violation table?

All the best,

John A
see the world's most beautiful baby girl at www.jzip.org



     
  <Prev Next>  
<<First
<Prev
Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016