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

Watch out: change for line numbers in SSMS 2014 Expand / Collapse
Author
Message
Posted Tuesday, April 22, 2014 2:48 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Saturday, October 11, 2014 11:41 AM
Points: 806, Visits: 723
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
https://connect.microsoft.com/SQLServer/feedback/details/857794/ssms-reports-incorrect-line-number-for-error-that-occurs-in-stored-procedures

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.


Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Post #1564042
Posted Tuesday, September 16, 2014 12:55 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, October 13, 2014 8:26 AM
Points: 68, Visits: 80
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
Post #1614218
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse