Archives of the TeradataForum
Message Posted: Wed, 18 Jun 2003 @ 20:56:10 GMT
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,
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|