Post reply

How many rows?

  • August 26, 2010 at 9:00 pm

    #226946

    Comments posted to this topic are about the item How many rows?

    Prashant Bhatt
    Sr Engineer - Application Programming

  • August 26, 2010 at 9:51 pm

    #1212703

    This really highlights why I don't like SQL Server's implicit data type conversion.

  • August 26, 2010 at 9:58 pm

    #1212705

    Nice question, thanks!

  • August 26, 2010 at 10:16 pm

    #1212711

    but the same will not return any rows when we use

    select * 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.

    Malleswarareddy
    I.T.Analyst
    MCITP(70-451)

  • August 26, 2010 at 11:13 pm

    #1212721

    The essence of this question is in the following:

    SELECT CONVERT(NVARCHAR(2),0) -- returns 0

    SELECT CONVERT(INT,N'') -- returns 0

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com

    Follow me on
    Twitter: @sqltwins

  • August 26, 2010 at 11:45 pm

    #1212745

    good one... thanks 🙂

  • August 27, 2010 at 12:06 am

    #1212749

    Good question. It points out that you have to be very careful with implicit conversions.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • August 27, 2010 at 12:12 am

    #1212752

    I am trying to find out "why" this behaviour is seen and believe that there is definitely something influencing this (I am just not able to find out what). It's not Data Type Precedence; but can be COLLATION Precedence.

    Based on what I found in BOL, I developed the following small test:

    SELECT CONVERT(NVARCHAR(2),0) -- returns 0

    -- returns 0, i.e. is NOT a Numeric value

    SELECT ISNUMERIC('')

    -- returns 0

    SELECT CONVERT(INT,N'')

    SELECT CONVERT(INT,N' ')

    SELECT CAST(N' ' AS INT)

    /*

    Data type conversion (Database Engine):

    "Character expressions that are being converted to an exact numeric data type must consist of digits, a decimal point, and an optional plus (+) or minus (-). Leading blanks are ignored. Comma separators, such as the thousands separator in 123,456.00, are not allowed in the string."

    */

    -- returns Error

    SELECT CONVERT(NUMERIC,N'')

    /*

    CAST & CONVERT :

    "SQL Server also returns an error when an empty string (" ") is converted to numeric or decimal."

    */

    If conversion to NUMERIC returns NULL, why does the conversion to INT succeed, and why does a blank string convert to 0?

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com

    Follow me on
    Twitter: @sqltwins

  • August 27, 2010 at 12:22 am

    #1212754

    ISNUMERIC is returing 0 so implicit conversation is not converting BLANK to ZERO. Therefore the reason behind this is something else.

    Thanks

  • August 27, 2010 at 1:07 am

    #1212766

    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 use

    select * 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.

    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • August 27, 2010 at 3:06 am

    #1212810

    Good One!

  • August 27, 2010 at 6:19 am

    #1212879

    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.

    Not so. You can easily prove that SQL Server does in fact convert blank strings to 0 with the following statement:

    select cast('' as int)

    ISNUMERIC doesn't work in this case because it doesn't actually try the conversion. It uses a different code path to determine whether a string is convertible to numeric, and that codepath does not follow exactly the same logic as the conversion code path. As Hugo said, this is best characterized as a bug in ISNUMERIC.

    For a better example of why you shouldn't depend on ISNUMERIC, try the following two queries:

    select cast('.' as float)

    select isnumeric('.')

    (edited to make final example more clear)

  • August 27, 2010 at 8:04 am

    #1212968

    Interesting question, thanks.

  • August 27, 2010 at 8:30 am

    #1212989

    Great question. QoTD regularly reinforces a best practice: make everything explicit.

  • August 27, 2010 at 11:49 am

    #1213147

    Thanks - we have another reason for ensuring specificity on our conversions.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic. Login to reply