Почему процедура хранения, которую я вызываю через ODBC, не работает в том же месте?
Я использую библиотеку freeodbC++ для доступа к данным в базе данных MS SQL Server 2000 (SP3? SP4?). В частности, я использую очень длинную и неприятную хранимую процедуру. Я могу наблюдать за выполнением процедуры в SQL Profiler, однако она имеет тенденцию останавливать обработку в определенный момент. Никаких кодов ошибок или исключений. Если я закомментирую вложенный оператор, который всегда является последним, он просто заканчивается немного раньше комментария. Я не пробовал радикально закомментировать всю эту чертову штуку ... Я устанавливаю тайм-аут запроса на 300 секунд. Вызываемый оператор обычно возвращается менее чем за 1 секунду, фактически не завершая SP.
Есть идеи?
ОБНОВЛЕНИЕ0: Если я запускаю SP через Query Analyzer или какой-либо другой инструмент ... он работает. Это просто через мое соединение ODBC, что он терпит неудачу.
ОБНОВЛЕНИЕ1: Когда я закомментирую код, выполнение заканчивается дальше в SP. Это заставляет меня думать, что у меня есть тайм-аут или ограничение буфера.
Ответы 4
Запустите процедуру из анализатора запросов и посмотрите, что произойдет. Вы можете использовать функцию RAISERROR () в процедуре, чтобы предоставить информацию трассировки обратно в окно сообщения, чтобы помочь вам отладить.
Вы пробовали использовать TRY и CATCH? Это может вызвать ошибку при вызове функции в вашей хранимой процедуре, которую вы не увидите.
BEGIN TRY
<Your code>
END TRY
BEGIN CATCH
DECLARE @ErrMsg nvarchar(max),
@ErrSeverity int,
@ErrState int
SELECT @ErrMsg = ERROR_MESSAGE(),
@ErrSeverity = ERROR_SEVERITY(),
@ErrState = ERROR_STATE()
RAISERROR (@ErrMsg,@ErrSeverity,@ErrState);
END CATCH
Не пробовал, спасибо за предложение.
Вы пробовали профилировать на стороне SQL Server, чтобы узнать, что происходит с вашим SPID?
Кроме того, я не использовал freeodbC++, но, возможно, там есть инструкция PRINT, которая ему не нравится. Вы также можете установить NOCOUNT ON, чтобы подавить сообщения о количестве строк. Опять же, это зависит от того, как freeodbC++ реагирует на эти «информационные» сообщения.
Это похоже на ошибку в freeodbC++, основанную на описанном вами стиле «замораживания». Начните с изучения процесса на стороне SQL, чтобы увидеть, действительно ли он завис, или ваша библиотека просто «умерла» на вас.
Спасибо ... Я спросил администратора базы данных об отслеживании SPID. Мы сделаем это завтра. Я думаю, что это ошибка freeodbC++, так как поддержка SP отсутствует.
Добавление ":: Sleep (30000);" сразу после того, как я вызываю команду execute для объекта оператора ODBC (и перед командой закрытия оператора), предотвращает преждевременный выход серверного процесса. Должна быть ошибка с freeodbC++ или ошибка конфигурации с моей стороны.
Спасибо за советы по устранению неполадок / отладке.
Об этом не упоминал. Он работает другими способами.