Archives of the TeradataForum

Message Posted: Fri, 19 Oct 2001 @ 10:44:41 GMT

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

Hi Geoffrey,

I also noticed that write-up in the documentation and in truth, I expect that it will end-up being the 'official' answer. Still, I hope for better.

Using the INSERT/VALUES statement, the random function appears to be working correctly - it's just that the row is hashed incorrectly and ends-up on the wrong AMP. What's interesting is that I can cast the RANDOM() result to a CHAR and the row still ends-up on the wrong AMP. Wouldn't that infer that maybe the problem isn't with the RANDOM() function at all, but rather a problem with the INSERT/VALUES statement (wouldn't that be a nightmare?).

My first reaction to this problem was that the workaround could use the INSERT/SELECT statement. That doesn't work in this situation because of locking. The INSERT/VALUES statement performs a row hash write lock, while the INSERT/SELECT statement places a write lock on the table. If you're designing for performance, then the INSERT/VALUES statement is certainly the better choice.

So if the RANDOM() function can't be used in an INSERT/VALUES statement, I would expect a fatal error to be generated. Given that it appears to be almost working (other than hashing correctly, even when cast), I would argue that it will probably take less effort by NCR to make it work correctly rather than add the code to make it a fatal error.

Either way, it's in the hands of NCR.

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