Archives of the TeradataForum
Message Posted: Fri, 19 Oct 2001 @ 10:44:41 GMT
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.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|