SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by bitbucket / SETTINGS - 1 / Latest Posts

RE: SETTINGS - 1

sqlnaive — Mon, 08 Apr 2013 07:28:29 GMT

Good basic question. And thanks to Tom and Hugo for the explanation. :-)

RE: SETTINGS - 1

jfgoude — Wed, 03 Apr 2013 07:04:02 GMT

almost too easythanks for this 1 point

RE: SETTINGS - 1

(Bob Brown) — Tue, 05 Mar 2013 11:20:46 GMT

Thanks for an easy one. They have been difficult lately.

RE: SETTINGS - 1

Hugo Kornelis — Mon, 04 Mar 2013 16:08:02 GMT

[quote][b]james.parker 62839 (3/4/2013)[/b][hr]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. :-P[/quote]I only noticed it today, and I decided to whip up a quick explanation here. I didn't (and still don't) have the time to also submit community content or other forms of feedback to Books Online.But feel free to do so if you want. You can use (or refer to) my post. All scenarios I described were tested on SQL Server 2012.

RE: SETTINGS - 1

EL Jerry — Mon, 04 Mar 2013 15:07:08 GMT

Easy question to start the week. Thank you, Ron, and thanks to Tom and Hugo for the explanation.Saludos,

RE: SETTINGS - 1

L' Eomot Inversé — Mon, 04 Mar 2013 10:20:38 GMT

[quote][b]james.parker 62839 (3/4/2013)[/b][hr]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. :-DIf 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. :-P[/quote]I guess you didn't realise that [quote]a decade or more after it was pointed out to them[/quote]meant that I (and others) did make some recommendations on this to MS a long time ago, with no effect at all, and I (and perhaps the others too) can't be bothered to try again.

RE: SETTINGS - 1

Revenant — Mon, 04 Mar 2013 09:41:01 GMT

Nice and easy one to start the week with - unusually easy for Ron.Thanks, Ron!

RE: SETTINGS - 1

SQLRNNR — Mon, 04 Mar 2013 08:06:48 GMT

thx for the question.

RE: SETTINGS - 1

jagpatel9 — Mon, 04 Mar 2013 07:42:48 GMT

Thank you for the question.Special thanks to Tom and Hugo for the explanation.

RE: SETTINGS - 1

mtassin — Mon, 04 Mar 2013 07:23:51 GMT

Nice question... the comments about it from Hugo and Tom are worth even more.Thanks guys!

RE: SETTINGS - 1

PHYData DBA — Mon, 04 Mar 2013 07:21:17 GMT

Nice Basic Question on a very unbasic topic. :cool:

RE: SETTINGS - 1

PHYData DBA — Mon, 04 Mar 2013 07:20:35 GMT

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. :-DIf 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. :-P

RE: SETTINGS - 1

kapil_kk — Mon, 04 Mar 2013 06:20:48 GMT

Thanks Hugo for the explanation

RE: SETTINGS - 1

Dineshbabu — Mon, 04 Mar 2013 05:29:19 GMT

Nice and Easy one..Thanks to Hugo & Tom for explaining about Divide By Zero.

RE: SETTINGS - 1

Thomas Abraham — Mon, 04 Mar 2013 05:08:46 GMT

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.

RE: SETTINGS - 1

Stewart "Arturius" Campbell — Mon, 04 Mar 2013 03:19:15 GMT

Good back-to-basics question, thanks Ronand thanks Tom & Hugo for the additional clarrifications

RE: SETTINGS - 1

Hugo Kornelis — Mon, 04 Mar 2013 01:28:08 GMT

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.[u]String truncation[/u]: 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).[u]Numeric truncation[/u]: 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.[u]Division by zero[/u]: 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.[u]Arithmetic overflow[/u]: Same behaviour as division by zero.

RE: SETTINGS - 1

Stuart Davies — Mon, 04 Mar 2013 01:27:25 GMT

Nice and gentle start to the week - thanks

RE: SETTINGS - 1

Koen Verbeeck — Mon, 04 Mar 2013 00:43:06 GMT

Nice question, thanks!

RE: SETTINGS - 1

kapil_kk — Sun, 03 Mar 2013 23:11:03 GMT

good basic question to start the week :-)+1

RE: SETTINGS - 1

Danny Ocean — Sun, 03 Mar 2013 23:02:17 GMT

:blush: I got the correct answer but chose wrong and lose easy point...but thanks it's nice question and good start of week...

RE: SETTINGS - 1

Lokesh Vij — Sun, 03 Mar 2013 22:02:31 GMT

[quote][b]demonfox (3/3/2013)[/b][hr]nice and easy Q for the monday ...and a great explanation by Tom ...thanks for Q & E[/quote]+1

RE: SETTINGS - 1

demonfox — Sun, 03 Mar 2013 21:57:45 GMT

nice and easy Q for the monday ...and a great explanation by Tom ...thanks for Q & E

RE: SETTINGS - 1

L' Eomot Inversé — Sun, 03 Mar 2013 13:43:50 GMT

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: [quote][b]Bol[/b][hr]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. [/quote]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

RE: SETTINGS - 1

db4breakfast — Sun, 03 Mar 2013 06:22:17 GMT

thanks for the question.

SETTINGS - 1

bitbucket-25253 — Sat, 02 Mar 2013 11:41:46 GMT

Comments posted to this topic are about the item [B]SETTINGS - 1[/B]