April 22, 2014 at 2:48 pm
There is a change in SSMS 2014 how line numbers are displayed in error messages. Instead of displaying the raw line number from SQL Server, SSMS 2014 adds the offset where the current batch starts to the error message. So if the query window reads:
PRINT 'This is the first batch'
go
PRINT 'This is the second batch'
go
PRINT 'This is a the third batch' 'and it has a syntax error'
The output message in SSMS 2014 is:
This is the first batch
This is the second batch
Msg 102, Level 15, State 1, Line 5
Incorrect syntax near 'and it has a syntax error'.
SSMS 2012 reports the error to be on line 1. You could argue that this is midly useful. However, there is a very nasty side effect. Consider:
CREATE TABLE PoorLittleNemo (a tinyint NOT NULL)
go
CREATE PROCEDURE ScenesFromANightsDream @a int AS
INSERT PoorLittleNemo(a) VALUES (@a)
go
EXEC ScenesFromANightsDream 800
go
DROP TABLE PoorLittleNemo
DROP PROCEDURE ScenesFromANightsDream
The output in SSMS 2014 is:
Msg 220, Level 16, State 2, Procedure ScenesFromANightsDream, Line 7
Arithmetic overflow error for data type tinyint, value = 800.
The statement has been terminated.
There are not seven lines in that stored procedure!
I find this extremely unhelpful, If I get an error from a stored procedure that I run from my query window (which often is a scratchpad of various ad hoc statements), I need to find where the current batch starts (Typically I only select a single statement) to compute the correct line number. And if I get the message from a co-worker, I have no idea how his query window looked like.
I have submitted a Connect item on
If you feel the same as me, vote up!
If you think this is a great improvement, vote down!
If you don't care - don't vote at all.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
September 16, 2014 at 12:55 pm
Hey There!!
SSMS 12/14 are operating the same way at the lower level.
The last example shows this perfectly. There are that many lines ( albeit they aren't shown ) Think about what SSMS is doing behind the scenes, right ? That is REALLY helpful, because now you are able to find out that your recursive task failed the xth time into the code.
I think I understand that challenge though, when you are anticipating the lower count for "physical" lines. But correct me if I am wrong; but I could have sworn the execution plans are operating the exact same way- thus this is a cosmetic change that is letting us see more information than previously provided.
Thoughts?
Jeremy
December 2, 2014 at 6:53 am
+1
This is very annoying to say the least, hope it gets corrected!
😎
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply