При отладке программ неизбежно обнаруживаются разнообразные ошибки. Рассмотрим некоторые типичные ситуации при работе в Query Analyzer.
Команда: Ошибка: Объяснение: Синтаксическая ошибка, пропущена буква в слове SELECT.
Команда: Ошибка: Объяснение: В команде вставки в списке полей перечислены два поля, а в списке значений — три значения.
Команда: Ошибка: Объяснение: Нельзя указывать явное значение для поля, у которого установлено свойство IDENTITY, т.е., для поля firm_num.
Команда: Ошибка: Объяснение: Нарушено ограничение внешнего ключа: мы пытаемся вставить ссылку на несуществующий отдел с номером 4.
Команда: Ошибка: Объяснение: Нарушено ограничение внешнего ключа: мы пытаемся удалить договор с номером 1, а к этому договору привязаны счета в таблице k_bill.
Команда: Ошибка: Объяснение: По умолчанию в SQL Server даты записываются в американском формате: месяц/день/год.
Команда: Ошибка: Объяснение: Если используются агрегирующие функции без группировки, в списке полей могут присутствовать только агрегирующие функции.
Команда: Ошибка: Объяснение: Если в нескольких таблицах, используемых в запросе, есть поля с одинаковыми названиями, то для обращения к таким полям следует использовать синтаксис имя_таблицы.имя_поля или псевдоним.имя_поля.
Команда: Ошибка: Объяснение: Нельзя использовать арифметические операции сравнения с подзапросом, если подзапрос возвращает несколько строк. Следует использовать ключевые слова ALL, ANY или EXISTS.
Команда: Ошибка: Объяснение: Длина значения в строковом поле не должна превышать длину поля, заданную при создании таблицы. На главную страницу
Александр
MSSQL. Ошибка The statement has been terminated
PHP 5.2.0
MSSQL 2003
Отправляю запрос на выполнение процедуры с параметрами. В результате получаю сообщение об ошибке "The statement has been terminated". При этом. Если результат процедуры не возвращает строк, то запрос отрабатывается без ошибок. Процедура нормально отрабатывает на родном клиенте, при этом не выдает никаких сообщений об ошибках.
Погугилил немного и полазил по багрепортам — ничего полезного найти не смог. Буду признателен за помощь в решении этого вопроса.
Сначала давайте посмотрим на ошибку: создадим таблицу с небольшими полями, а затем попытаемся вставить больше данных, чем они могут вместить.
Машина Baby длиннее, чем 20 символов, поэтому при выполнении оператора INSERT получаем ошибку:
Это засада, поскольку у нас нет идей относительно того, какое поле вызвало проблемы! Это особенно ужасно, когда вы пытаетесь вставить множество строк.
Чтобы пофиксить ошибку, включите флаг трассировки 460
Флаг трассировки 460 был введен в SQL Server Sevice Pack 2, Cummulative Update 6, и в SQL Server 2017. (Вы можете найти и загрузить последние обновления с SQLServerUpdates.com.) Вы можете включить флаг на уровне запроса, например:
Теперь, если выполнить запрос, он покажет вам, какой столбец усекается, а также какая строка. В нашем случае мы имеем только одну строку, но в реальной жизни много полезней будет знать, какая строка вызвала ошибку:
Вы можете включить этот флаг трассировки как на уровне запроса (в нашем примере выше), так и на уровне сервера:
Этот оператор включает его для всех, а не только для вас — поэтому сначала договоритесь со своей командой разработчиков, прежде чем включать его. Это изменит номер ошибки 8152 на 2628 (как показано выше), означающее, что если вы строили обработку ошибок на основании этих номеров, вы сразу получите другое поведение.
Я любитель включения этого флага трассировки на время отладки и изучения, но как только обнаруживаю источник проблем, выключаю его, снова выполнив команду:
В нашем случае, как только мы идентифицировали избыточную длину машины Baby, необходимо либо изменить название машины, либо изменить тип данных в нашей таблице, чтобы сделать размер столбца больше. Можно также предварительно обрабатывать данные, явно отсекая избыточные символы. Мастерская по разборке данных, если хотите.
Не оставляйте этот флаг включенным
По крайней мере, имеется связанный с этим один баг в SQL Server 2017 CU13: табличные переменные будут выбрасывать ошибки, говорящие, что их содержимое усекается, даже если никакие данные не вставляются в них.
Вот простой скрипт, чтобы проверить, пофиксили ли это поведение:
SQL Server 2017 CU13 всё еще сообщает об усечении строки, даже если строка не вставляется:
Переключение с табличной переменной на временную таблицу приводит к ожидаемому поведению:
Это замечательный пример, почему не следует использовать флаги трассировки по умолчанию. Конечно, они могут пофиксить проблемы, но они также могу вызвать непредсказуемое или нежелательное поведение. (И, вообще, я не фанат табличных переменных.)