CommandTime Out

← →
Анонимщики (2008-05-22 15:07) [0]

Delphi2007, MS SQL 2005; SQL Native Client; ADO

Не работает CommandTimeout при выполнении хранимой процедуры (
ADOStoredProc1.ExecProc
) в случае, если эта процедура имеет вид вроде:

while (1=1)
begin
set @a = 0;
end

Если же она содержит долговыполняющийся запрос, то все работает.
С чем это связано, не вполне ясно, но как бы добиться ожидаемой работы?

← →
Reindeer Moss Eater © (2008-05-22 15:19) [1]

очевидно причина примерно такого же плана как и в следующем случае :

BBreak := False;

repeat
until BBreak;

btn1.onclick(sender...);
begin
BBreak := true;
end;

Если же идет долгий селект, то очевидно при фетче сервер отвлекается на обработку таймаутов.

← →
Анонимщики © (2008-05-22 15:24) [2]

Меня причина интересует только для того, чтобы проблему можно было обойти.
К тому же, видимо, ответ угадан неверно (могу привести косвенные аргументы).
Кроме того, у меня была надежда, что таймаут контролируется на клиенте, а не на сервере, поскольку в хелпе написано, в частности, следующее:
Use the CommandTimeout property ... to allow the cancellation of an Execute method call, due to delays from network traffic or heavy server use.
А проблема проявляется не только и не столько при выполнении подобного рода ХП, а при большой загрузке сервера.
И последнее, не понял, какое отношение ко всему этому имеет фетч.

← →
Reindeer Moss Eater © (2008-05-22 15:27) [3]

фетч записей и код твоей мудрой процедуры выполняются в разных контекстах. Один в контексте sql другой в tsql.

← →
Анонимщики © (2008-05-22 15:31) [4]

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

← →
sniknik © (2008-05-22 15:33) [5]

тебе нужен аналог Application.ProcessMessages из дельфи... дать "подышать" и sql серверу, в своем бесконечном цикле.
(а то кто таймаут то обрабатывать будет?)

попробуй простенький селект туда вставить... да хотя бы так SELECT @a = 0 вместо set @a = 0; (не зря же рекомендуют новые методы вместо старых, может в них есть вызов ихнего "ProcessMessages")

← →
Reindeer Moss Eater © (2008-05-22 15:34) [6]

из исходных данных известно, что при селектах таймаут работает, а при кручении циклов нет.
даже если таймаутами занимается клиент, я не думаю, что адо с клиента "видит" что там делается в sp и понимает разницу между двумя этими случаями и поэтому ведет себя по разному.
Вывод:
сервер тоже участвует в этом процессе.
в чем разница этих случаев с точки зрения сервера?
в разных контекстах.

логика.

← →
Анонимщики © (2008-05-22 15:37) [7]

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

while (1=1)
begin
select @abcd = IDFile from lst_Files where FileSize = 336;
end;

Так что предложение "подышать" не проходит.

← →
Reindeer Moss Eater © (2008-05-22 15:37) [8]

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

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

← →
Анонимщики © (2008-05-22 15:42) [9]

Неважно, кто что думает, тут знать нужно.
Кроме того, отменить выполнение можно следующим образом.

1. В ExecuteOptions для TADOStoredProc устанавливаем eoAsyncExecute в True.

Для выполнения ХП делаем следующее:

type THackAdoDataSet = class(TCustomADODataSet); var fullTime: Integer; begin fullTime := 0; repeat Sleep(1000); fullTime := fullTime + 1; if _Command(THackAdoDataSet(ADOStoredProc1).Command.CommandObject).State = 0 then break; until fullTime > ADOStoredProc1.CommandTimeout; _Command(THackAdoDataSet(ADOStoredProc1).Command.CommandObject).Cancel; end;

Сомневаюсь, что Ваша логика безупречна и предлагаю не разворачивать о ней дискуссий.

← →
Анонимщики © (2008-05-22 15:47) [10]

--Reindeer Moss Eater © (22.05.08 15:37) [8]

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

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

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

← →
Reindeer Moss Eater © (2008-05-22 15:51) [11]

Кроме того, отменить выполнение можно следующим образом.

тогда в чем проблема.
отменяй.

← →
Анонимщики © (2008-05-22 15:54) [12]

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

← →
Reindeer Moss Eater © (2008-05-22 15:55) [13]

ну тогда помедитируй над [1]

← →
Анонимщики © (2008-05-22 15:59) [14]

Не сердитесь, но приведенные Вами аргументы мне кажутся невероятными и недостаточными. Я бы вам посоветовал меньше гадать, а отвечать только в случае хорошего ориентирования в вопросе.

← →
Reindeer Moss Eater © (2008-05-22 16:01) [15]

а я бы все же посоветовал помедитрировать над тем циклом

← →
Анонимщики © (2008-05-22 16:30) [16]

Хорошо, спасибо.

← →
Anatoly Podgoretsky © (2008-05-22 16:34) [17]

> Анонимщики © (22.05.08 15:42) [9]

Странный какой то код, ассинхронный запрос превращаем в синхронный, почему бы просто не использовать синхронный? Зачем же разогревать процессор?

← →
Анонимщики © (2008-05-22 16:46) [18]

Не совсем понял, вам Sleep"ы не нравятся? Или я неправильно понял?

← →
sniknik © (2008-05-22 16:48) [19]

> помедитрировать над тем циклом
кстати да,
ADOCommand1.CommandText:= "WAITFOR DELAY ""000:00:10""";
ADOCommand1.CommandTimeout:= 3;
ADOCommand1.Execute;
вываливается по таймауту через 3 сек, а не завершается через 10. (и вставленная в твой цикл задержка в 1 сек например, тоже его разблокирует)

← →
sniknik © (2008-05-22 16:49) [20]

> Странный какой то код
это пример, и да, в таком виде он действительно не работает как должен бы...

← →
Анонимщики © (2008-05-22 16:51) [21]

Я говорил, что

while (1=1)
begin
select @abcd = IDFile from lst_Files where FileSize = 336;
end;

не реагирует на таймаут точно так же, как и
while (1=1)
begin
set @a = 0;
end

Я не знаю, что такое WAITFOR DELAY, но не понимаю, какие выводы из Вашего сообщения нужно сделать?

← →
Анонимщики © (2008-05-22 16:54) [22]

> Странный какой то код
--это пример, и да, в таком виде он действительно не работает как должен бы...

В нем нет в начале ADOStoredProc1.ExecProc, а перед отменой нужно проверять, получен результат или еще нет. А так оно работает. В чем странность?

← →
Reindeer Moss Eater © (2008-05-22 17:13) [23]

ADOCommand1.CommandText:= "WAITFOR DELAY ""000:00:10""";
ADOCommand1.CommandTimeout:= 3;
ADOCommand1.Execute;
вываливается по таймауту через 3 сек, а не завершается через 10. (и вставленная в твой цикл задержка в 1 сек например, тоже его разблокирует)

У меня по таймауту отваливается и вот это:

while (1=1)
begin
set @a = 0;
end

← →
Reindeer Moss Eater © (2008-05-22 17:16) [24]

дурили нас с самого начала

← →
Reindeer Moss Eater © (2008-05-22 17:25) [25]

используй TADOCommand

← →
Анонимщики © (2008-05-22 17:42) [26]

Так Вам нужно было проверить.
У Вас отваливается TADOCommand, а TADOStotedProc не отваливается?
Какая вас СУБД и какой провайдер, можете сказать?

← →
sniknik © (2008-05-22 18:04) [27]

> Я не знаю, что такое WAITFOR DELAY,
задержка на период, или ожидание до указанного времени

> но не понимаю, какие выводы из Вашего сообщения нужно сделать?
while (1=1)
begin
set @a = 0;
WAITFOR DELAY "000:00:01"
end
проверь

> У меня по таймауту отваливается и вот это:
может быть. не знаю от чего зависит... у меня есть разница, как и у автора.

> используй TADOCommand
я именно его и использовал (TADOStotedProc вообще ни под каким видом не пользую, даже для тестов)

D7, MSSQL2005, Native Client

У Вас отваливается TADOCommand, а TADOStotedProc не отваливается?

С TADOCommand у меня то же самое

Подозреваю, что вопрос все же в клиенте.
Как можно узнать, какие именно dll-и используются?

> У Вас отваливается TADOCommand, а TADOStotedProc не отваливается?
у меня, если это ко мне, отваливается TADOCommand в случае с WAITFOR -> [27], и "висит" без него, если запрос как у тебя в -> [0], а что и как там с TADO/StoredProc(/Query/Table) мне пофигу, не пользовался и не буду, убраны с палитры компонент за ненадобностью.

← →
Анонимщики (2008-05-22 23:45) [33]

Я это спрашивал у Reindeer Moss Eater, поскольку у него хоть что-то работает.
А пользоваться можно чем угодно, главное умеючи.

Можно узнать параметры ваших файлов sqlncli.dll? Я так понимаю, что это и есть реализация клиента поставщика данных для Native MS SQL. У меня этот файл находится в "C:\Windows\system32"

Мои данные:
Версия (файла) - 2005.90.1399.00
Дата - 14.10.2005
Версия (продукта) - 9.00.1399.06

← →
Анонимщики (2008-05-24 16:21) [35]

тук-тук

Я хочу то же самое спросить у всех прохожих. Поделитесь информацией.

2005.90.3042.0
10 февраля 2007
9.00.3042.00

но пробовал не только с найтивным клиентом, со старым тоже (и на 2000-ом сервере), без разницы.

чем не устаривает изменить запрос?

У меня проблемы не на запросе, а при сильной загрузке сервера.

Но меня больше интересовал Reindeer Moss Eater, поскольку у него все хорошо.
У меня же с версией, как в [37], то же самое, что и изначально (в [34]).

CommandTime Out Найти похожие ветки