Let’s say you want to insert (or, for our example, update) a whole set of random numbers into a table.
You may try this:
UPDATE table SET rnum = RAND()
…only you find, to your amazement, that SQL Server has put the same number into each row.
Hmm.
In SQL Server, when rand() is called multiple times in the same query (e.g. for multiple rows in an update statement), it usually returns the same number.
Two problems:
* Firstly, the rand() function returns a number between 0 and 1.
* Secondly, when rand() is called multiple times in the same query (e.g. for multiple rows in an update statement), it usually returns the same number (which I suspect your algorithm above is trying to solve, by splitting it into multiple calls)
My favourite way around this problem is to use a function that’s guaranteed to return a unique value each time, like NEWID(), convert it to binary, and use it as the seed.
UPDATE table SET rnum = RAND(convert(binary(16),NEWID()))
This works because NEWID() is guaranteed to return a new GUID (a globally unique 16-byte number) each time it’s invoked. We must convert this to binary before using it, as RAND() won’t accept GUIDs as its seed.
So, although RAND() ordinarily gives the same random value for each row in an update, we get over the problem with RAND by giving it a different seed for each row using a function that gives a different result for each row.
Jeremy Smyth's blog 