Время ожидания хранимой процедуры истекло, но нормально при запуске из SSMS

У меня есть хранимая процедура, которая выдает ошибку «Время ожидания истекло».

Используемый код — ADO/VB6.

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

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

Ошибка будет воспроизводиться каждый раз для сотен попыток, независимо от того, запускаете ли вы код VB6 в режиме отладки или нет, а затем вдруг все волшебным образом снова начнет работать. Потом через какое-то время та же проблема появится снова.

Я не уверен, сколько кода здесь разместить, в этом нет ничего сложного; это в основном;

Set adoCommandObject.ActiveConnection = ...{open ADODB.Connection object}
Set rs = CreateObject("ADODB.Recordset")
Call rs.Open(adoCommandObject, , adOpenForwardOnly, adLockReadOnly)'Timeout occurs here

Я наблюдал в профилировщике, но это не дало никаких подсказок, за исключением того, что иногда я видел операторы «SET NO_BROWSETABLE ON» / «SET NO_BROWSETABLE OFF», возникающие до и после запуска sp.

Я искал в сети, но не смог найти удовлетворительной помощи для этого; На данный момент я готов попробовать что угодно (кроме перезаписи в .NET, к сожалению, это не вариант!)


timeout ado vb6
person DannykPowell    schedule 22.05.2009    source источник
comment
Пара вопросов: Вы получаете Timeout Expired через длительный промежуток времени или сразу? Если это долго, согласен ли профилировщик с тем, что продолжительность команды была такой большой?   -  person Chris Simpson    schedule 22.05.2009
comment
Get Timeout Expired по прошествии некоторого времени - 30 секунд или около того - я думаю, что это за настройка тайм-аута, вероятно, по умолчанию. Да, профилировщик соглашается - после того, как ошибка выдается в коде VB6, вы видите завершение sp в профилировщике с отмеченной большой продолжительностью.   -  person DannykPowell    schedule 23.05.2009
comment
Вы определили решение, поскольку я нахожусь в похожей ситуации!   -  person    schedule 15.08.2010
comment
не совсем, я не участвовал лично, но я считаю, что проблема все еще время от времени возникает. Кажется, помните, что разработчик упомянул что-то об операторе return/или они удалили return 0/добавили, и это возымело эффект? Стоит попробовать. Удачи - если вы найдете решение, пожалуйста, напишите. P.S. Аналогично ;-)   -  person DannykPowell    schedule 21.08.2010

Ответы (2)


arrow_upward
3
arrow_downward

Я думаю, вы слишком много думаете об этом. Не обижайтесь, но если вы используете MSSQL, это так же просто, как кто-то оставляет окно запроса открытым, и это связывает базу данных. Это легко проверить. У меня была такая же беда раньше. Я запускал хранимые процедуры до того, как у них не было времени ожидания, которые обычно запускались немедленно, но сидели всю ночь и не запускались. Только чтобы узнать, что другой сотрудник оставил окно запроса открытым. Закройте их окно и пуф, оно наконец запускается. Проверьте это, вы будете удивлены, что блокировка таблицы может сделать с вашим приложением.

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

person Randall    schedule 24.06.2009
comment
Возможно ты прав. Я уклонился от проблемы, чтобы завершить то, что мне нужно было сделать в то время, не до конца вникая в суть проблемы. Если это произойдет снова, я буду иметь это в виду; Спасибо - person DannykPowell; 04.07.2009
comment
Я столкнулся с той же проблемой. И причиной была блокировка стола. Спасибо. +1 - person Max; 21.08.2010

arrow_upward
0
arrow_downward

  • Возможно, скрывается какой-то код, который случайно устанавливает время ожидания соединения или команды на очень маленькое значение.
  • Возможно, процедура действительно иногда требует времени для запуска, например. если сервер делает что-то еще или статистика устарела
  • Можете ли вы зафиксировать случай тайм-аута с помощью профилировщика, и если да, действительно ли процедура занимает много времени для выполнения?

Как описано здесь, SET NO_BROWSETABLE ON аналогичен использованию ДЛЯ ПРОСМОТРА при выборе. Я предполагаю, что он автоматически генерируется ado, когда он думает, что вы можете обновить этот набор записей. Вероятно, есть свойство набора записей, которое вы могли бы установить, чтобы остановить их выпуск, но маловероятно, что проблема именно в этом.

person Rory    schedule 22.05.2009
comment
Спасибо за Ваш ответ. Первое предложение - нет, я просмотрел весь код/код типа GetOpenConnection, и нет настройки тайм-аута. 2: Определенно не проблема с нагрузкой на сервер. Я запускал нагрузочные тесты jmeter раньше в приложении, где мы нажимали на этот код/используемый sp очень оптимизирован/также используется в реальном времени, когда клиенты возлагают на него гораздо большую нагрузку, чем я ударил его как одноразовый. Об этой проблеме не сообщается в реальных системах, а только в тестовой системе, с которой я разрабатываю, так что, возможно, это проблема с самой базой данных..? См. мой комментарий выше re. захват в профайлере - person DannykPowell; 23.05.2009