Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

SETTINGS - 1 Expand / Collapse
Author
Message
Posted Saturday, March 2, 2013 11:41 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, November 6, 2014 1:00 PM
Points: 5,333, Visits: 25,277
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

Before posting a performance problem please read
Post #1425875
Posted Sunday, March 3, 2013 6:22 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 10:18 AM
Points: 386, Visits: 368

thanks for the question.


--------------------------------------------------------------------------------------
Hai Ton
My Db4Breakfast blog.
Post #1425939
Posted Sunday, March 3, 2013 1:43 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 4:21 PM
Points: 7,928, Visits: 9,653
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
Post #1426006
Posted Sunday, March 3, 2013 9:57 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, December 11, 2014 9:19 PM
Points: 1,129, Visits: 1,164
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
Post #1426079
Posted Sunday, March 3, 2013 10:02 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, December 2, 2014 9:20 AM
Points: 1,372, Visits: 1,567
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
Guidelines for answers on Performance questions

Link to my Blog Post --> www.SQLPathy.com

Follow me @Twitter

Post #1426080
Posted Sunday, March 3, 2013 11:02 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, February 6, 2014 4:15 AM
Points: 1,242, Visits: 1,546
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 !!!
www.GrowWithSql.com

Post #1426088
Posted Sunday, March 3, 2013 11:11 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, December 14, 2014 11:09 PM
Points: 1,962, Visits: 2,406
good basic question to start the week
+1



_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
Post #1426092
Posted Monday, March 4, 2013 12:43 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, December 18, 2014 12:52 PM
Points: 13,636, Visits: 11,509
Nice question, thanks!



How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1426103
Posted Monday, March 4, 2013 1:27 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:13 AM
Points: 3,348, Visits: 3,644
Nice and gentle start to the week - thanks

-------------------------------
Posting Data Etiquette - Jeff Moden
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
Post #1426115
Posted Monday, March 4, 2013 1:28 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 4:36 PM
Points: 6,133, Visits: 8,398
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 MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #1426116
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse