Home Page for the TeradataForum

Archives of the TeradataForum

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

  <Prev Next>   <<First <Prev

Subj:   Re: A problem using the RANDOM() function
From:   John Hall

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
  Top Home Privacy Feedback  
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023