December 10, 2009 at 9:13 pm
Comments posted to this topic are about the item How long is a NULL?
December 10, 2009 at 10:13 pm
I did not really knew that.
December 11, 2009 at 4:53 am
The documentation is slightly different; 2005 BOL says that when "replacement_value" is returned, it will be implicitly converted to the type of "check_expression" while 2000 BOL just demands both expressions to be of same type.
This was the last straw for me, I haven't typed "ISNULL" into a code window since but switched to always using COALESCE.
Which I was expecting someone would mention. Perhaps there are circumstances where usage of ISNULL is warranted, but such use would require good commenting as most think of ISNULL and COALESCE as being equal.
COALESCE returns the full 10-character "replacement_value" in both versions.
December 11, 2009 at 5:28 am
Wow, that is just bizarre. I wouldn't have called that in a million years, and I don't feel the least bit bad about getting it wrong. Great question!
-----
a haiku...
NULL is not zero
NULL is not an empty string
NULL is the unknown
December 11, 2009 at 5:45 am
Yes, I found this bizarre behaviour the first time I encountered it. Just did a quick experiment on a SQL 2008 installation and I see it still does the same there, so guess we're probably stuck with this now. Pity, because it's utterly non-intuitive that NULL should have a size at all!
December 11, 2009 at 6:19 am
Also a void string take 1 CHAR:
SET CONCAT_NULL_YIELDS_NULL ON
SELECT ISNULL('abcd'+''+null,'1234567890')
Result: 123456
December 11, 2009 at 7:20 am
[font="Comic Sans MS"]
as well ..
SET CONCAT_NULL_YIELDS_NULL ON
SELECT ISNULL('abcd'+NULL+NULL,'1234567890')
Results : 123456
[/font]
[font="Comic Sans MS"]--
Sabya[/font]
December 11, 2009 at 9:00 am
ahhh ... just another case of getting 'caught' by an 'implicit' converstion !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 11, 2009 at 11:20 am
Interesting behavior ... I had to look up the YIELDS_NULL ON before I answered the question, then still got it wrong. Had I thought about it longer, I would have realized that there is only one answer that actually fits. But I jumped the gun and chose the wrong one. Oh well, yet another one I got wrong. *beginning to question my choice in career now* 😀
December 11, 2009 at 11:26 am
Arto ahlstedt (12/10/2009)
the NULL that is appended somehow contributes to the total length of the expression with an effective length of 1.
Got to love the "somehow"...
Since NULL can be of any datatype, SQL Server always has a hard time determining what datatype was meant when it encounteres the constant NULL. In this case, since it's appended to a string, it's obviously a string as well. So that makes it a varchar (char could have been used as well, but SQL Server chooses varchar in these cases). Both of these have a default length of 1.
The result of concatenating varchar(5) ('abcde') with varchar(1) is of course varchar(6), so that is the datatype of the first argument. And since ISNULL returns the same datatype as the first argument, the result is also varchar(6).
Here is some code to repro this:
SELECT 'abcde' AS a, 'abcde' + NULL AS b INTO TestTable;
go
EXEC sp_help TestTable;
go
DROP TABLE TestTable;
December 12, 2009 at 7:09 am
Hugo Kornelis
Thank you for explanation. Could you also explain why "under SQL Server 2000, the result is '1234' regardless of the number of NULLs appended"?
December 12, 2009 at 12:09 pm
vk-kirov (12/12/2009)
Hugo KornelisThank you for explanation. Could you also explain why "under SQL Server 2000, the result is '1234' regardless of the number of NULLs appended"?
Thanks!
First, please be aware that my explanation for the SQL Server 2005 behaviour is based on guesswork and then verified by experiments. I don't have a SQL Server 2000 instance running, so I can only guess there.
Also be aware that, as far as I know, there is no documentation about how SQL Server guesses the datatype of a NULL. As with any undocumented feature, it can change between sessions, or even between service packs or hotfixes.
My guess is that on SQL Server 2000, the engine assumes a zero length string for NULL. That, or some completely different conversion takes place - if I recall correctly, a lot of the implicit type conversion stuff was changed between 2000 and 2005.
Bottom line - if you need NULL to be the datatype you expect it to be, always use CAST(NULL AS datatype)
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply