Как я могу получить фактический номер строки хранимой процедуры из сообщения об ошибке? - PullRequest
103 голосов
/ 30 декабря 2010

Когда я использую Sql Server и возникает ошибка, в сообщении об ошибке указывается номер строки, который не имеет корреляции с номерами строк в хранимой процедуре. Я предполагаю, что разница связана с пробелами и комментариями, но так ли это на самом деле?

Как я могу связать эти два набора номеров строк друг с другом? Если бы кто-нибудь мог дать мне хотя бы указатель в правильном направлении, я был бы очень признателен.

Я использую SQL Server 2005.

ТИА!

Ответы [ 8 ]

106 голосов
/ 31 декабря 2010

IIRC, он начинает считать строки с начала пакета, который создал этот процесс. Это означает либо начало скрипта, либо последний оператор «GO» перед оператором create / alter proc.

Более простой способ увидеть это - извлечь текст, который SQL Server использовал при создании объекта. Переключите вывод в текстовый режим (CTRL-T с сопоставлениями клавиш по умолчанию) и запустите

sp_helptext proc_name

Скопируйте, вставьте результаты в окно скрипта, чтобы получить подсветку синтаксиса и т. Д., И используйте функцию goto line (я думаю, что CTRL-G), чтобы перейти к сообщаемой строке ошибки.

24 голосов
/ 04 декабря 2015

По привычке я помещаю LINENO 0 сразу после BEGIN в мои хранимые процедуры. Это сбрасывает номер строки - в этом случае в ноль. Затем просто добавьте номер строки, сообщенный сообщением об ошибке, к номеру строки в SSMS, где вы написали LINENO 0, и в бинго - у вас есть номер строки ошибки, представленный в окне запроса.

7 голосов
/ 18 апреля 2013

На самом деле это Error_number() работает очень хорошо.

Эта функция начинает отсчет с последнего оператора GO (Batch Separator), поэтому, если вы не использовали пробелы Go и он по-прежнему показывает неправильный номер строки - добавьте к нему 7, как в хранимой процедуре вВ строке № 7 разделитель партий используется автоматически.Так что если вы используете Cast (Error_Number () + 7 как Int) как [Error_Number] - вы получите желаемый ответ.

5 голосов
/ 09 февраля 2017

Если вы используете блок захвата и используете RAISERROR () для любой проверки кода в блоке Try, тогда строка ошибки сообщается о том, где находится блок Catch, а не где произошла реальная ошибка.Я использовал это, чтобы прояснить это.

BEGIN CATCH
  DECLARE @ErrorMessage NVARCHAR(4000);
  DECLARE @ErrorSeverity INT;
  DECLARE @ErrorState INT;

  SELECT 
     @ErrorMessage = ERROR_MESSAGE() + ' occurred at Line_Number: ' + CAST(ERROR_LINE() AS VARCHAR(50)),
     @ErrorSeverity = ERROR_SEVERITY(),
     @ErrorState = ERROR_STATE();

  RAISERROR (@ErrorMessage, -- Message text.
     @ErrorSeverity, -- Severity.
     @ErrorState -- State.
  );

END CATCH
2 голосов
/ 30 января 2011

вы можете использовать это

CAST(ERROR_LINE() AS VARCHAR(50))

, и если вы хотите создать таблицу журнала ошибок, вы можете использовать это:

INSERT INTO dbo.tbname( Source, Message) VALUES ( ERROR_PROCEDURE(), '[ ERROR_SEVERITY : ' + CAST(ERROR_SEVERITY() AS VARCHAR(50)) + ' ] ' + '[ ERROR_STATE : ' + CAST(ERROR_STATE() AS VARCHAR(50)) + ' ] ' + '[ ERROR_PROCEDURE : ' + CAST(ERROR_PROCEDURE() AS VARCHAR(50)) + ' ] ' + '[ ERROR_NUMBER : ' + CAST(ERROR_NUMBER() AS VARCHAR(50)) + ' ] ' +  '[ ERROR_LINE : ' + CAST(ERROR_LINE() AS VARCHAR(50)) + ' ] ' + ERROR_MESSAGE())
1 голос
/ 08 ноября 2018

В TSQL / Хранимые процедуры

Вы можете получить ошибку, такую ​​как:

Сообщение 206, Уровень 16, Состояние 2, Процедура myproc, Строка 177 [Стартовая Строка 7]

Это означает, что ошибка в строке 177 в пакете. Не 177 в SQL. Вы должны увидеть, с какого номера строки начинается ваша партия, в моем случае [7], а затем вы добавляете это значение к номеру строки, чтобы найти, какое утверждение неверно

1 голос
/ 31 октября 2016

вы можете получить сообщение об ошибке и строку ошибки в блоке catch следующим образом:

'Ms Sql Server Error: - ' + ERROR_MESSAGE() + ' - Error occured at: ' + CONVERT(VARCHAR(20),  ERROR_LINE())
0 голосов
/ 16 июля 2015

Длинный ответ: номер строки отсчитывается от оператора CREATE PROCEDURE плюс любые пустые строки или строки комментариев, которые у вас могли быть над ним, когда вы фактически выполняли оператор CREATE, но не считали никаких строк перед GO оператор…

Мне было гораздо проще создать сохраненный процесс, с которым можно поиграться, чтобы подтвердить:

GO

-- =============================================
-- Author:          <Author,,Name>
-- Create date: <Create Date,,>
-- Description:     <Description,,>
-- =============================================
CREATE PROCEDURE ErrorTesting
       -- Add the parameters for the stored procedure here
AS
BEGIN
       -- SET NOCOUNT ON added to prevent extra result sets from
       -- interfering with SELECT statements.
       SET NOCOUNT ON;

       -- Insert statements for procedure here
       SELECT 1/0

END
GO

После того, как вы его создали, вы можете переключить его на ALTER PROCEDURE и добавьте несколько пустых строк над комментариями, над и под первым оператором GO, чтобы увидеть эффект.

Одна очень странная вещь, которую я заметил, состояла в том, что мне пришлось запустить EXEC ErrorTesting в новом окне запроса вместо того, чтобы выделять его в нижней части того же окна и запускать ... Когда я это делал, номера строк продолжали расти!Не уверен, почему это произошло ..

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...