Question

I have SQL Server 2005 Standard Service Pack 2 9.00.4053.00 (Intel X86)

Table has close to 30 million rows..

If I do

SELECT GETDATE(), * FROM
<table>

Identical Date and time value is returned including milliseconds part.. though query took more then 3 minutes to complete…

I have already read

http://sqlblog.com/blogs/andrew_kelly/archive/2008/02/27/when-getdate-is-not-a-constant.aspx

http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/66507b8b-4a74-44c1-9637-3ab5f75db6a0

One of the link I posted (marked answer) suggest that prior to SQL 2005 GETDATE was deterministic
although SQL 2000 BOL states GETDATE is nondeterministic

If I do an update with millions of rows

UPDATE tableName
SET dateColumn = GETDATE()

I know you really want to do

DECLARE @DT datetime
SET @DT = GETDATE()
UPDATE table
SET datecol =@DT

I am really confused

What would be expected behavior?

1. In case of select statement I posted earlier
2. Behavior of update statement

Considering you are updateing a datecolun on a table with 100 million rows
Would datecolumn will have identical date and time in milliseconds….?

Answer 1

Following on from Martin Smith’s answer, The determinism referred to was a change in udf behaviour. In SQL Server 2000, you could not use GETDATE in a udf. You can in SQL Server 2005. See this link too

As Martin Smith said, some functions are evaluated per column, per query. Not per row. GETDATE is one, RAND is another.

If you do need row by row evaluation of GETDATE then wrap it in udf.

Edit:

NEWID is statistically unique. It must be evaluated row by row so you don’t have the same value appear in another row. Hence the CHECKSUM(NEWID()) trick to generate row by row random numbers…