Устранение неполадок в сложном хранимом процессе - это гораздо больше, чем просто определение, можно ли запустить его или нет, и поиск шага, который не будет запущен.Что наиболее важно, так это то, действительно ли он возвращает основные результаты или выполняет правильные действия.
Существует два вида хранимых процедур, которые нуждаются в обширных способностях для устранения проблем.Сначала процедура, которая создает динамический SQL.Я никогда не создаю один из них без входного параметра @debug.Когда этот параметр установлен, у меня есть proc, который печатает SQl-статистику, как если бы он выполнялся, а не запускался.Почти каждый раз это сразу приводит вас к проблеме, поскольку вы можете увидеть синтаксическую ошибку в сгенерированном коде SQL.Вы также можете запустить этот sql-код, чтобы увидеть, возвращает ли он ожидаемые вами записи.
Теперь со сложными процессами, которые имеют много шагов, влияющих на данные, я всегда использую входной параметр @test.С параметром @test я делаю две вещи: сначала я делаю откат действий, чтобы ошибка в процессе разработки не испортила данные.Во-вторых, мне нужно отобразить данные перед откатом, чтобы увидеть, какими были бы результаты.(На самом деле они появляются в обратном порядке в процедуре; я просто думаю о них в этом порядке.)
Теперь я могу видеть, что вошло в таблицу или было удалено из таблиц, не влияя на данные постоянно,Иногда я могу начать с выбора данных, как это было до каких-либо действий, а затем сравнить их с последующим прогоном выбора.
Наконец, я часто хочу регистрировать действия сложного процесса и точно видеть, какие шагиполучилось.Я не хочу, чтобы эти журналы откатывались, если процесс обнаружил ошибку, поэтому я настроил табличную переменную для нужной мне информации регистрации в начале процесса.После каждого шага (или после ошибки в зависимости от того, что я хочу войти), я вставляю в эту переменную таблицы.После оператора отката или фиксации я выбираю результаты табличной переменной или использую эти результаты для записи в постоянную таблицу журналирования.Это может быть особенно хорошо, если вы используете динамический SQL, потому что вы можете регистрировать SQL, который был запущен, а затем, когда что-то странное не сработало на prod, у вас есть запись о том, какой оператор был выполнен, когда он не удался.Вы делаете это в табличной переменной, потому что они не выходят за рамки при откате.