Поделиться через


Ограничения отладки SQL

Обновлен: Ноябрь 2007

Этот раздел применим к:

Выпуск

Visual Basic

C#

C++

Web Developer

Экспресс-выпуск

Тема не применяется Тема не применяется Тема не применяется Тема не применяется

Standard

Тема не применяется Тема не применяется Тема не применяется Тема не применяется

Pro и Team

Тема применяется Тема применяется Тема применяется Тема применяется

Условные обозначения таблицы:

Тема применяется

Применяется

Тема не применяется

Не применяется

Тема применяется, но команда по умолчанию сокрыта

Команда или команды, скрытые по умолчанию.

В этом подразделе описываются некоторые общие ограничения по отладке SQL.

Многоуровневая отладка SQL

  • При отладке многоуровневых приложений невозможно использовать Пошаговую отладку для захода из кода на уровень приложения (C#, Visual Basic, or C++) в код на SQL Server 2005 (T-SQL или SQL/CLR). Вместо этого установите в коде хранимой процедуры точку останова и нажмите клавишу Продолжить (F5) для выполнения кода до точки останова. Чтобы достигнуть желаемого места без использования точек останова, можно использовать выполнение до курсора. Обратите внимание, что внутри уровня SQL Server 2005 можно переключаться между кодом T-SQL и SQL/CLR.

  • Невозможно совершать шаг другим способом из кода хранимой процедуры назад в код на уровне, который вызвал хранимую процедуру. При необходимости продолжить отладку после возвращения на уровень приложения, следует установить точку останова в коде приложения за точкой, из которой была вызвана хранимая процедура.

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

    Во время отладки необходимо временно отключить объединение подключений. Для этого установите "Pooling=false" в строке подключения, используемой для подключения к SQL Server. По окончании отладки удалите этот атрибут из строки подключения, и объединение подключений будет включено по умолчанию.

  • Управляемое приложение может подключаться к источнику данных SQL Server с помощью Поставщика данных платформы .NET Framework для SQL Server, с которым получается лучшая производительность, чем в случае с OLE DB или ODBC. В одном и том же сеансе отладчика можно производить управляемую отладку и отладку SQL.

    Если запущено управляемое приложение и производится подключение к приложению с помощью отладчика, пользователю предоставляется выбор, какой вид отладки выполнять. Если необходимо выполнить отладку SQL, следует выбрать отладку SQL, а если необходимо выполнить отладку кода SQL/CLR, тогда нужно также указать и управляемую отладку.

  • Отладку SQL можно выполнять только после подключения к работающему приложению. Однако заметьте, что отлаживать можно только подключения к базам данных, создаваемые после завершения Присоединения. Таким образом, если приложение вызывает хранимую процедуру, занимающую много времени, присоединиться к подключению, вызвавшему хранимую процедуру, невозможно, возможно присоединиться только к новым подключениям, которые вызывают хранимую процедуру после подключения к приложению.

  • Если отладка выполняется через подключение с использованием OleDbDataAdapter, ожидание в течение значительного времени после достижения точки останова вызовет тайм-аут подключения. При попытке продолжить отладку после этого тайм-аута (например, если выбрать Продолжить в меню Отладка), отладчик завершит свою работу (вместо продолжения выполнения). Это является ожидаемым поведением. Завершение работы отладчика происходит, потому что OleDbDataAdapter, в отличие от SqlDataAdapter, не создает исключение при возникновении тайм-аута. Для устранения этой проблемы при работе с OleDbDataAdapter установите большое значение для тайм-аута.

    Дополнительные сведения об установке значения тайм-аута для поставщиков данных платформы .NET Framework см. в разделах OleDbCommand.CommandTimeout Property и SqlCommand.CommandTimeout Property документации библиотеки классов .NET Framework.

    Самые последние сведения о технологиях MDAC см. на веб-узле, посвященном Microsoft Universal Data Access https://www.microsoft.com/data.

Другие ограничения

  • Для отладки триггеры должны быть активизированы: непосредственная отладка триггеров невозможна. Вместо этого запустите отладку в хранимой процедуре, которая заставит триггер сработать.

  • В отладке среды выполнения подзапросы выборки (например, в объединении) могут заполнить сетевой буфер. Это может вызвать остановку нормально работающего кода во время отладки. Для получения большего количества данных используйте RecordSet.MoveNext и RecordSet.NextRecordSet.

  • Если имя хранимой процедуры содержит кавычки, можно получить от отладчика сообщение об ошибке. Дополнительные сведения см. в разделе Ошибка при процедурах отладки с именами, содержащими кавычки.

  • Кэшированные значения автоматически не изменяются. Не следует ожидать, что изменения локальных переменных или параметров, кэшированных интерпретатором SQL, будут вступать в силу во временных фреймах, соответствующих пошаговому проходу по оператору SQL. Хотя значение можно изменить, его проверка может никогда не состояться. Невозможно принудительное обновление кэшированных значений. Кэшированные значения существуют потому, что план выполнения SQL Server устанавливает, что значения для некоторых переменных не будут динамически загружаться для каждого выполнения процедуры или ссылки на нее. Для получения дополнительных сведений найдите термин "SHOWPLAN" в документации SQL Server 2005.

  • Невозможно присоединиться к собственным процессам SQL Server с одновременной отладкой хранимой процедуры.

См. также

Основные понятия

Безопасность отладчика

Отладка SQL

Ограничения на команды и функции отладчика