Остановить запрос в потоке

← →
MsGuns © (2006-09-07 16:54) [0]

В методе Execute потока:

try
ADOCom.Execute;
if terminated then
Free; // Завершить поток
...
except
...
end;

Запрос может выполняться достаточно долго и есть необходимость из главного потока принудительно его снять.
Однако выполнить Terminate не удается, пока запрос не выполнится. Очевидно, надо что-то типа WaitForSingleObject, но не врубаюсь, как это реализовать.
(WinXP)

Спасибо за помощь

← →
ANB © (2006-09-07 16:56) [1]

Обломись. Используй асинхронное выполнение запроса и будет тебе счастье.

← →
ANB © (2006-09-07 17:09) [2]

Кстати, если сильно охота - можешь его и в отдельном потоке запускать. Только придется писать цикл ожидания его окончания (если надо ждать) с проверкой нажатия кнопочки "Стоп".
В ADO вроде как это более менее аккуратно пишитеся. Вот с одаком я помудохался.

← →
sniknik © (2006-09-07 17:10) [3]

но даже при ассинхронном, выполнение на сервере похоже не останавливается... по закрытии на клиенте просто прекращает ждать результат. (очень на то похоже)
т.е. если буквально, то остановить его не удастся, сервер или доделает его либо прекратит по ошибке.

← →
Ega23 © (2006-09-07 17:13) [4]

> т.е. если буквально, то остановить его не удастся, сервер
> или доделает его либо прекратит по ошибке.

Серьёзно? Т.е. я, например, зафигачил на выполнение запрос на 100000000 записей, а потом резко через TaskManager клиента убил, то на сервере он всё равно будет выполняться???

Нифига себе...

← →
ANB © (2006-09-07 17:26) [5]

> sniknik © (07.09.06 17:10) [3]

Не знаю, как через ADO, а через DBLIB нормально снимается. Проэкспериментировать можно с QA.

← →
Ega23 © (2006-09-07 17:30) [6]

> Проэкспериментировать можно с QA.

Кистате, в QA не так просто прервать выполнение запроса...
Да и не совсем понятно, как он написан: с использованием DBLIB, ADODB или прямые вызовы API...

← →
ANB © (2006-09-07 18:19) [7]

> Ega23 © (07.09.06 17:30) [6]

не через ADO - однозначно. Вообщето QA ставится вместе с клиентом, а в клиенте ставится DBLIB . . .

Короче, если в QA запрос не срубается, то и в клиенте его аккуратно не срубить.

> Серьёзно? Т.е. я, например ...
ну я сужу по некоторым экспериментам с аксесс... приеду домой подробнее расскажу. а вообще конечно могу ошибаться. и естественно от сервера многое зависит, наверняка.

> Не знаю, как через ADO, а через DBLIB нормально снимается.
он и в ADO нормально снимается... но, есть некоторые признаки(+ догадки) по которым допустил, что "снятие" это попросту обман, запрос на сервере не прекрашается, просто рвется канал с сервером (тем потоком который выполняет запрос), новый начинается в новом потоке паралельно.

сначала догадки. попробуйте представить каким образом вы бы делали подобное снятие будь вы разработчиком сервера, какие были бы накладные расходы на опрос клиента, или поддержание канала для того чтобы клиент мог сообшить. ну и даже если бы этот признак о уже ненужности данных запроса пришол на сервер, как его проверять в процессе выполнения запроса? пришлось бы выполнение дробить на части, читать куски данных(страниц) вместо целых только для того чтобы проверить этот флаг - признак "снятости". т.е. существенно замедлить выполнение, и это при том что подавляющее большинство запросов (~ 99,99%) сняты не будут, а большинстово из этого большинства не успеют прокрутить даже одну итерацию до проверки как уже будут выполнены...
ну и что бы вы сделали? я бы лично плюнул нафиг на этот 0,01% (процент который еще можно сократить если писать грамотно) ради того чтобы хоть немного ускорить остальные... и почемуто кажется, что у разработчиков sql серверов похожие мысли.

теперь признаки, раньше пробовал аксесс, сейчас перепроверил на MSSQL, тест простой выполняем асинхронно запрос (такое же получение данных) на большой результат (у меня 173 тыс. записей, размер одной записи по сумме полей гдето 300байт), по ходу выполнения снимаем его, и тутже начинаем выполнять снова (фактически на кнопке висит Close; Open;), ну вот, если на эту кнопку жать часто (очень часто ;о)), то гдето на 50м клике в режиме "дребезжасчего" пальца запросы начинают тормозить (вернее получение данных, количество выводится) а еще через какоето время практически останавливаются и выдается сообщение системы о нехватке памяти и желательном увеличении файла подкачки. (на одной машине sql сервер и прога. для уточнения бы еще тест провести когда они на разных машинах... но, тест у меня от аксесса, делал давно , на котором кстати подобного сейчас не получил, раньше было аналогично, но тогда машина у меня была раз а n-цать слабее счас похоже не успеваю жать :) (а менять чтонибудь в тесте лень))
вот. потому и решил, похоже всетаки продолжает выполнятся, или система память ну успевает отдать, или еще что, но точно хорошего мало. (проб, мне лично хватило, чтобы понять что так лучше не делать, и всеми силами избегать. но вот сказать точно, что так оно и есть не могу, потому и сказал предположительно. (т.е. "похоже ..."))

Прежде всего спасибо всем откликнувшимся ;)

Для прерывания запроса есть метод Cancel и он работает. В результате его выполнения клиент "оживает" почти сразу, а вот сервер "бросает это дело" несколько позже.
Убедиться в этом легко с помощью того же QA, если сначала запустить длительный запрос, а потом его тормознуть. И наблюдать картинку процессов на сервере.

Я нашел решение, но оно нехорошее. Можно явно тормознуть запрос из гл.потока, если передать ему указатель на TADOCommand в конструкторе нити. Однако плохо то, что нет гаратнии, что к моменту, когда осн.поток будет выполнять снятие процесса, сервер вернет данные и поток приступит к их обработке.

Остановить запрос в потоке Найти похожие ветки