Archives of the TeradataForum

Message Posted: Tue, 09 Jul 2002 @ 16:13:33 GMT

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

Dave and Jose are both right - those are big limitations.

Ignoring Dave and Jose's points for the sake of argument, I did think about this as well, but I don't think that it will guarantee uniqueness. Here's my reasoning:

The problem is that Fastload loads to an empty table, each row getting a unique ROWID (where RowID consists of the hash value of the PI plus a uniqueness value). So let's say that I have two rows that I just fastloaded and their PI results in a hash synonym (with a hash value of '123456'). The first row will be given a uniqueness value of '1' and the second row will get a uniqueness value of '2'.

These rows are then INS/SEL'd into the target table. OK so far.

The next time I run the Fastload into an empty table, let's say that I have two more rows that happen to hash to the same value as the first two rows (hash value of '123456'). Instead of getting uniqueness values of '3' and '4', they would receive uniqueness values of '1' and '2' again. The rows only need to be unique within a table (not systemwide) and uniqueness values can be re-used.

Now when these rows are INS/SEL'd into the target table, you'll get a uniqueness violation.

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