dogramone (8/26/2010)
This really highlights why I don't like SQL Server's implicit data type conversion.
Good point. Always ensure your types match, or use explicit conversion when they don't.
(Though the empty string also converts to 0 in explicit conversion)
malleswarareddy_m (8/26/2010)
but the same will not return any rows when we useselect * from #temp where code ='0'
this will return nothing.When we use 0 in quotes it will not return any no of rows.Implicits conversion happens from varchar to int.but it will not happen from int to varchar.We want to convert explicitly.
select * from #temp where code =convert(int,'0')
this will return three rows even we put zero in sigle quotes.
You are confusing some things. The first query doesn't do any conversion - both the column (code) and the constant ('0') are already of the character data type, so no conversion at all is required. And because the UPDATE has changed all the '0' strings to '' (empty) strings, no rows match.
In the second query, you are making it even more complicated. With the quotes, the constant is character; without them, it is integer. The explicit convert will convert it to integer (a no-op if you leave out the quotes). Then SQL Server will convert the contents of the code column to int for the comparison, again converting the empty string to the value 0. So the end effect will not be any different from
select * from #temp where code = 0;
You are right, though, that implicit conversion will not happen from integer to character. But for a different reason. Implicit conversions always follow the rules of data type precedence, and integer has a higher precedence. The only way to force conversion from integer to character is by using explicit conversion:
select * from #temp where code = convert(nvarchar(2), 0);
This will convert the integer value 0 to a character data type ('0'). The code column is also character, so no further conversion is required and the comparison is done. This is equivalent to using
select * from #temp where code = N''0';
No rows will be returned.
Nakul Vachhrajani (8/27/2010)
If conversion to NUMERIC returns NULL, why does the conversion to INT succeed, and why does a blank string convert to 0?
Answer to the first question: Because the rules for conversion to numeric are not the same as the rules for conversion to integer. And for conversion to float or money, yet other rules are used.
Speculative answer to the second question: The conversion algorithm must have some logic to deal with leading zeroes, as I expect both '00003' and '3' to convert to the same integer value. This same logic should also be used to consider '0000' and '0' as equal. It could be that the algorithm is too agressive, in allowing the last zero to be left out as well?
Or it could be by design. In my eyes, there are only two logical outcomes when converting an empty string to a numericall value: error or 0.
hardik.doshi (8/27/2010)
ISNUMERIC is returing 0 so implicit conversation is not converting BLANK to ZERO. Therefore the reason behind this is something else.
I consider this a bug in ISNUMERIC. According to Books Online, ISNUMERIC returns 1 if the "expression can be converted to at least one of the numeric types". Since the empty string can be converted to not one but several numeric types (int, money, and real), the return vallue should have been 1.