suppose
isnull(some_column, getdate()) >= getdate()
where logic is if some_column is null this expression should always be true. However will this always be so (since between two evaluations of getdate() some time has passed and they won't be equal) ?
No, is not safe. You are facing so called runtime constants expressions, of which
GETDATE()
is the bookcase example, which are evaluate once at query startup and the subsequently the cached evaluated value is used. However each occurence is evaluated separately once and the two evaluation can fall on the separate sides of the datetime precision boundary, resulting in two different values.A simple test reveals how this happens:
In my case this was hit right away:
I'm not addressing the question how to better do this (you already got plenty of advice) but the underlying question whether your assumption about the run-time execution is right (is not):
GETDATE()
twice in a statement will be evaluate twiceSince you are looking for true in the condition, you don't need to use
getDate()
twice. Just put in a very large date instead...For example:
as in
which returns 1.
Alternatively you can do it properly and check for the null explicitly:
Since you are invoking
GETDATE()
twice, this may fail, though most of the time it will work right.You can do the following to mitigate:
Why do you want to use date. I mean there is no reason to ask sql server to evaluate/process for a default true condition. You can instead use
In SQL Server 2000 and previous versions, getdate() is a deterministic function evaluated ONCE per SQL sentence. From 2005 and on, getdate is NOT deterministic, it's evaluated each time so you should assign the value to a variable.