Post reply

SETTINGS - 1

  • March 2, 2013 at 11:41 am

    #394296

    Comments posted to this topic are about the item SETTINGS - 1

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • March 3, 2013 at 6:22 am

    #1592743

    thanks for the question.

    --------------------------------------------------------------------------------------
    Hai Ton
    My Db4Breakfast blog.

  • March 3, 2013 at 1:43 pm

    #1592799

    Nice clear and unambiguous question. Back to basics, really. Possibly difficult for people who are used to working with ANSI WARNINGS ON, but pretty basic for the rest of the world.

    The explanation is a bit incomplete though. The reference is to the right BOL page, but the text quoted from that page is actually irrelevant because it's saying that even when ANSI_WARNINGS is set to ON some statements (parameter passing to SP or to UDF, assignment to variables) don't follow the ansi standard for treating overflow and zero divide errors that occur in INSERT or UPDATE statements - actually I can't understand why anyone would think it might or should, but there's no harm in making it clear. It says nothing at all about what happens when ANSI_WARNINGS is set to OFF and that's what the question is about. There's no text at all in the explanation that describes what happens when ANSI_WARNINGS is OFF.

    In fact some of the other text on the BOL page is a bit of a mess:

    Bol

    When set to ON, the divide-by-zero and arithmetic overflow errors cause the statement to be rolled back and an error message is generated. When set to OFF, the divide-by-zero and arithmetic overflow errors cause null values to be returned. The behavior in which a divide-by-zero or arithmetic overflow error causes null values to be returned occurs if an INSERT or UPDATE is tried on a character, Unicode, or binary column in which the length of a new value exceeds the maximum size of the column. If ANSI_WARNINGS is ON, the INSERT or UPDATE is canceled as specified by the ISO standard. Trailing blanks are ignored for character columns and trailing nulls are ignored for binary columns. When OFF, data is truncated to the size of the column and the statement succeeds.

    The third sentence appears to say that NULL values occur when zero divide or aithmetic overflow errors occur and ANSI_WARNINGS is OFF, and that this includes the case when INSERT or UPDATE tries to stuff more into a character or unicode column than will fit. However, this is contradicted by the sixth sentence, so perhaps the third sentence applies when ANSI_WARNINGS is ON? But that would contradict the first sentence! The obvious correction is to get rids of the third sentence and make teh fourth sentence say that it applies to putting overlength data into character, unicode, or binary string columns (ie grab the last bit of the third sentenbce and put it into the fourth sentence).

    It isn't all that unusual for a BOL page to be a bit of a mess, but it usually gets fixed when it's pointed out. This time MS has left it a mess for a decade or more after it was pointed out to them (the offending text dates from BOL for SQL 2000, or perhaps even earlier).

    edit: spelling

    Tom

  • March 3, 2013 at 9:57 pm

    #1592866

    nice and easy Q for the monday ...

    and a great explanation by Tom ...

    thanks for Q & E

    ~ demonfox
    ___________________________________________________________________
    Wondering what I would do next , when I am done with this one :ermm:

  • March 3, 2013 at 10:02 pm

    #1592867

    demonfox (3/3/2013)

    nice and easy Q for the monday ...

    and a great explanation by Tom ...

    thanks for Q & E

    +1

    ~ Lokesh Vij

    Guidelines for quicker answers on T-SQL question[/url]
    Guidelines for answers on Performance questions

    Link to my Blog Post --> www.SQLPathy.com[/url]

    Follow me @Twitter

  • March 3, 2013 at 11:02 pm

    #1592873

    :blush: I got the correct answer but chose wrong and lose easy point...

    but thanks it's nice question and good start of week...

    Thanks
    Vinay Kumar
    -----------------------------------------------------------------
    Keep Learning - Keep Growing !!!

  • March 3, 2013 at 11:11 pm

    #1592877

    good basic question to start the week 🙂

    +1

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • March 4, 2013 at 12:43 am

    #1592887

    Nice question, thanks!

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

  • March 4, 2013 at 1:27 am

    #1592898

    Nice and gentle start to the week - thanks

    -------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
    There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
    I would never join a club that would allow me as a member - Groucho Marx

  • March 4, 2013 at 1:28 am

    #1592899

    Like Tom, I too think the explanation in Books Online is very unsatisfactory. So I did some tests to check a few of the issues.

    In this specific question, two things are at stake: truncatiing a string (both on assignment to variable and during insertion in a table) and implicit truncating to integer.

    String truncation: With ANSI_WARNINGS OFF, this is always accepted, with no error or warning message. With ANSI_WARNINGS ON, truncation on assignment to a variable is still accepted, but truncating when inserting to the table generates an error message and causes the statement to fail. Changing the ANSI_WARNINGS to ON in the query posted in the question will result in this error message, and the SELECT runs and shows only the column headers (as there is no row inserted).

    Numeric truncation: Truncating the number as part of the conversion to integer is always allowed and will never generate a warning or error, regardless of the ANSI_WARNINGS setting.

    According to Books Online, two other issues to beware of are division by zero and arithmetic overflow.

    Division by zero: Any attempt to divide by zero will always cause an error. With ANSI_WARNINGS ON, this aborts the statement, but allows the rest of the batch to continue. So if the error takes place in the SET, the SET will not be executed (variable is still NULL), and the INSERT executes (inserting a NULL value). If the error is in the INSERT itself, no row is inserted.

    Arithmetic overflow: Same behaviour as division by zero.

    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/

  • March 4, 2013 at 3:19 am

    This was removed by the editor as SPAM

  • March 4, 2013 at 5:08 am

    #1592958

    When I saw the question, I knew it must be Monday. "Oriented in space and time? Check."

    Thanks Ron for this, and your many other contributions.

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • March 4, 2013 at 5:29 am

    #1592965

    Nice and Easy one..

    Thanks to Hugo & Tom for explaining about Divide By Zero.

    --
    Dineshbabu
    Desire to learn new things..

  • March 4, 2013 at 6:20 am

    #1592976

    Thanks Hugo for the explanation

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • March 4, 2013 at 7:20 am

    #1592997

    Tom and/or Hugo -

    I understand and may even agree your dismay in the BOL description given with this answer.

    I do not see any recomendations for correcting it or a better wording.

    Not even a commment on the Community Additions. 😀

    If it has been such a mess for you for that long, post a correction with the BOL.

    People read and act on the comments made in the BOL Community Additions by others. 😛

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

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