November 3, 2009 at 12:32 am
"The length of the value returned is always equal to or less than the field length of the checked expression"....
November 3, 2009 at 1:34 am
From BOL:
Return Types
Returns the same type as check_expression.
In this case, a cast from varchar(12) to varchar(10)
November 3, 2009 at 5:06 am
I find these questions great training - thanks!
November 3, 2009 at 6:00 am
This is the main reason I make it a habit to use COALESCE rather than ISNULL unless there's a reason I need the behavior of ISNULL.
November 3, 2009 at 6:07 am
Noel McKinney (11/3/2009)
This is the main reason I make it a habit to use COALESCE rather than ISNULL unless there's a reason I need the behavior of ISNULL.
I prefer ISNULL because of performance.
November 3, 2009 at 6:32 am
Carlo Romagnano (11/3/2009)
Noel McKinney (11/3/2009)
This is the main reason I make it a habit to use COALESCE rather than ISNULL unless there's a reason I need the behavior of ISNULL.I prefer ISNULL because of performance.
Interesting, I can't recall coming across references to performance comparisons between COALESCE and ISNULL, but yes, there does seem to be a slight advantage in CPU time with ISNULL that could be noticed over a very large number of rows. However, in my environment, preventing unintended truncation of string values is more important than slight performance gains.
November 3, 2009 at 6:36 am
Carlo Romagnano (11/3/2009)
Noel McKinney (11/3/2009)
This is the main reason I make it a habit to use COALESCE rather than ISNULL unless there's a reason I need the behavior of ISNULL.I prefer ISNULL because of performance.
So, do you have any repro code that actually demonstrates a performance difference between COALESCE and ISNULL? If so, please post!
The only situation I know of is when an expression in COALESCE is a subquery - in those cases, ISNULL can be found to perform better. But how often does one actuallly need an entire subquery in COALESCE or ISNULL?
Like Noel, I use COALESCE rather than ISNULL. Because of the weird datatyping rules of ISNULL, but also because it supports more than two arguments, and because it's ANSI standard. The only reasons I'd ever prefer ISNULL are
1) If I have to use it in a view or computed column where the column has to be not nullable - any COALESCE expression is always nullable; ISNULL is only nullable is the second argument is nullable.
2) If any of the arguments has to be a subquery, because of the potential performance problems COALESCE has with those - and since this is acutally caused by an optimizer weakness, I'd make a note to check if the optimizer has finally improved in this respect after every version or servicepack upgrade.
November 3, 2009 at 6:51 am
I've almost 'grown up' (professionally) with microsoft's sql standard, thus I'm not too familiar with ANSI standard.
I've played with COALESCE before, but I find ISNULL is sufficient for my requirements; I haven't had to deal with multiple arguments possibly being null and I don't work with large number of rows...
But it is good to know how to 'skin the cat' a different way
Thanks for the input guys
November 3, 2009 at 7:00 am
I too go with using ISNULL because I discovered it before COALESCE.
For multiple NULL values until I discovered COALESCE, I'd just chain ISNULL's
ISNULL(<test value>,ISNULL(<test value 2>,<final value))
etc.
November 3, 2009 at 6:03 pm
Wasn't aware of this behaviour of isnull !
November 4, 2009 at 10:11 am
Noel McKinney (11/3/2009)
This is the main reason I make it a habit to use COALESCE rather than ISNULL unless there's a reason I need the behavior of ISNULL.
I wasn't aware of that ISNULL property or that COALESCE does NOT truncate that way. I've been switching to using COALESCE on occasion because I understand that it's ansi-standard, but now I have an additional reason to use COALECSE.
Thank for a good question.
June 6, 2013 at 12:51 am
October 4, 2016 at 2:51 pm
question is old, but taught me something new. thanks
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply