Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.08.08;
Скачать: [xml.tar.bz2];

Вниз

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

 
First_May   (2002-07-16 10:11) [0]

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


 
BAY   (2002-07-16 10:12) [1]

никак :(


 
Kaban   (2002-07-16 10:13) [2]

Только если запрос выполняется в отдельном потоке


 
Fareader   (2002-07-16 10:21) [3]

2Kaban © (16.07.02 10:13)
Я бы не советовал так делать - на клиенте ты поток убьешь, а сервер то уже "напрягся"


 
Kaban   (2002-07-16 10:26) [4]

Это уже другой вопрос, корректно это делать или нет


 
Desdechado   (2002-07-16 10:34) [5]

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


 
First_May   (2002-07-16 11:06) [6]

Kaban
Мне это и надо, так как пользователь передумал получать данный результат. Можешь подкинуть примерчик или где можно это посмотреть. Буду ОЧЕНЬ благодарен.


 
Alexandr   (2002-07-16 11:10) [7]

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


 
Fareader   (2002-07-16 11:14) [8]

Alexandr © (16.07.02 11:10) Вот я же об этом


 
Kaban   (2002-07-16 11:23) [9]

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


 
First_May   (2002-07-16 11:31) [10]

Да, некоторые выполняются довольно долго и оптимизировать их не удается. А бывает такие ситуация, когда данные для запроса введены неправильно или просто передумал и не хочу его выполнять. Может кто нибудь подскажет, как выполнить запрос в отдельном потоке и что бы его можно было бы всетаки прервать?


 
Alexandr   (2002-07-16 11:35) [11]

есть еще способ прерывания с помощью генератора.
Это рулез и прерывает запрос именно на сервере.
Вот только писать мне здесь про это в очередной раз влом.
Достало уже.
поищи сам...
на www.ya.ru сходи...


 
Kaban   (2002-07-16 11:35) [12]

1. У Тайксейра и Паченко, по-моему, в первом томе был пример
2. \Borland\Delphi5\Demos\DB\BKQuery


 
First_May   (2002-07-16 11:49) [13]

Kaban © (16.07.02 11:35)
В этом примере запрос продолжает выполняться до тех пор, пока он не выполнится или не снимешь задачу. А мне бы хотелось, что бы приложение продолжало работать, а запрос прекратил бы свое выполнение, пусть даже через некотороые время.


 
Kaban   (2002-07-16 11:55) [14]

я конечно этот пример не смотрел, но в начале там сказано
{ Demostrates how to execute a query in a background thread. This
files contains the main user interface for this program. The background
query code is in ResltFrm }

Наверное, нужно просто остановить второй поток. Ты с потоками когда нибудь работал?


 
Johnmen   (2002-07-16 11:56) [15]

>Alexandr © (16.07.02 11:35)
>есть еще способ прерывания с помощью генератора.
>Это рулез и прерывает запрос именно на сервере.
>Вот только писать мне здесь про это в очередной раз влом.

Будь человеком, не ломайся ! :-)))))))
А то очень хочется чего-нибудь рулезного, а не рутинного. ;o)




 
First_May   (2002-07-16 12:09) [16]

Немного работал, но в это примере действительно происходит то, что я писал выше. А это мне не подходит.

Согласен с Johnmen, ведь я хочу просто узнать кто и как решает подобную задачу, а так отвечать просто не хорошо. :(


 
Kaban   (2002-07-16 12:11) [17]

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


 
Alexandr   (2002-07-16 12:13) [18]

читать тут

http://ib.demo.ru/devinfo/generator.htm


сколько раз уже говорили: "Читайте на ночь каждый день сайт WWW.IBASE.RU" там есть ответы на все вопросы, даже еще не заданные вами...


 
Johnmen   (2002-07-16 12:21) [19]

>Alexandr © (16.07.02 12:13)
>читать тут
> http://ib.demo.ru/devinfo/generator.htm

Нечто подобное я и предполагал....
Вот только чтобы установить(сбросить) значение ген-ра придется все равно создавать поток...:))))



 
Fareader   (2002-07-16 12:22) [20]

Да действительно интересный и действенный способ прервать запрос со стороны сервера.


 
Alexandr   (2002-07-16 12:31) [21]

поток дасоздавать придется... Но при этом запрос прервется на сервере и при этом совершенно корректно, в отличие от варварского способа с прибитием потока.

У меня вот есть несколько тяжелых SP (это сложные отчеты и они выполняются дольше 5 секунд), так вот, я в них эту проверочку вставил и теберь как администратор переключаю генератор и все эти тяжелые запросы прерываются и юзеру сообщение выдается типа "запрос прерван администратором".
Это полезно бывает, когда несколько человек одновременно запустят по тяжелому запросу и сервер заклинит... (это особенно касается SuperServer и даже в Yaffil SuperServer с этим гораздо легче)


 
kaif   (2002-07-16 12:54) [22]

А кто-нибудь уже работал с IB6.5 ?
Его разработчики уверяют, что там можно убить запрос из соседнего потока...


 
Kaban   (2002-07-16 12:56) [23]

2 kaif © (16.07.02 12:54)
А ты читал все, что написано выше. там говориться о том,
>>что там можно убить запрос из соседнего потока...


 
kaif   (2002-07-16 13:04) [24]

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


 
Alexandr   (2002-07-16 13:12) [25]

Видели мы IB6 и после этого смотреть на IB6.5 неохота.
2kaif: Ведь ты же уже на этом попадался... Помнишь, когда у тебя последнее соединение не отключалось от базы и ты его грохал? Чего там с базой было? а? Вот ты из соседнего коннекта прибьешь запрос, а у тебя sweep который на этом запросе был тоже прибьется, и кранты базе... Исправлено только Yaffil.

А мой способ с генераторами не ждет фетча - он в логику запроса залазит. Так что тут мне про фетч втирать ненадо...


 
kaif   (2002-07-16 13:25) [26]

2 Alexandr © (16.07.02 12:31)
Разумеется, я не хочу спорить с решениями, когда в логике ХП удается прервать запрос (кода эту ХП нормальные люди писали). Однако тут на форуме я часто вижу такие запросы мелькают:
SELECT .. WHERE ... IN (SELECT... WHERE ...IN (SELECT
и т. д. И такие вещи у людей по 2 часа работают, а не по 5 сек. И если Borland что-то сделал для несчастных, хотелось об этом подробнее узнать. :)
Не хочу показаться задавалой... Но ведь это правда! Плюс многие вообще вынуждены работать с базами, которые изначально уродски были сделаны...
А у IB6.5 больше шансов, так как это все же коммерческий продукт. Ведь на коммерческие версии IB5.6 вроде нареканий было немного...


 
Alexandr   (2002-07-16 13:38) [27]

2kaif: Ну, блин, все в кучу смешал.
Ладно, пусть тут будет очередной диспут
1) SELECT .. WHERE ... IN (SELECT... WHERE ...IN (SELECT
такие запросы говорят о кривизне рук разработчика и это его личная проблема.
Кстати такой запрос также легко снимается генератором... О чем я и говорил
2)Уродски сделанные базы надо переделывать.
3) знаешь, пусть этот IB6.5 будет хоть трижды коммерческим, он лучше от этого не станет. Программы пишет не Borland , а конкретные разработчики, И те кто писал IB на заре IB6 перешли в проект Firebird, а в Борланде набрали новую команду для реанимации IB. Так что вот.
4) Существуют огромное количество багов, исправленных в Firebird по сравнению с IB, и существует огромное количество багов, не исправленных ни там ни там, а исправленных только в Yaffil.


Вообщем, на эту тему можно говорить до бесконечности...


 
First_May   (2002-07-16 13:52) [28]

Спасибо всем, я кое что понял.


 
AlexGreG   (2002-07-16 16:04) [29]

Интересно, а с Ораклом можно такую штуку сотворить?


 
kaif   (2002-07-16 16:16) [30]

Извини, Alexandr, я не знал, что разработчики IB ушли из проекта. Это многое меняет.
>2)Уродски сделанные базы надо переделывать.
Совершенно согласен. Но я работаю, как независимый разработчик и мне легко говорить. Многие, к сожалению, думают иначе...
Боюсь окончательно тебя разозлить, но ведь есть проекты (например, просто клиенты типа IBConsole или IBExpert), где юзверь (в данном случае юзверь и разработчик совпадают) руками запрос пишет. И вот, допустим, чел допустил декартово произведение или еще какую глупость (с кем не бывает, по невнимательности). Что же теперь бедняге прикажешь делать?


 
Anatoly Podgoretsky   (2002-07-16 16:27) [31]

Отрезать руку, затем вторую


 
Fareader   (2002-07-16 17:21) [32]

2Anatoly Podgoretsky © (16.07.02 16:27)
кардинальное и очень оптимистичное решение проблемы


 
Alexandr   (2002-07-17 07:29) [33]

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


 
kaif   (2002-07-17 12:52) [34]

2 Alexandr © (17.07.02 07:29)
Есть такой старый анекдот (да простит меня модератор).
- Как уберечься от венерических заболеваний?
- Нужно надеть презерватив, затем замотать изолентой, сверху еще один презерватив. И главное - ни в коем случае не трахаться.


 
Alexandr   (2002-07-17 13:09) [35]

да. Согласен.
Но ведь не смотря на СПИД, и другие болезни :) люди все равно тр@#ются.

Вывод понятен?



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.08.08;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.52 MB
Время: 0.008 c
1-24019
anod
2002-07-28 23:08
2002.08.08
Подкиньте идейку


3-23881
Prog_mail
2002-07-17 12:26
2002.08.08
Подскажите компонент для отчета


3-23964
maxim2
2002-07-19 12:42
2002.08.08
Копирование из SQL запроса в таблицу


1-24049
newUser
2002-07-25 13:26
2002.08.08
Lockfile


7-24242
arbiter
2002-04-02 20:20
2002.08.08
Properties файлов





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский