Идея по использованию UDF

← →
Andrey (2002-09-10 17:20) [0]

Бродил я по FAQ-у и набрел я на статейку
http://delphi.mastak.ru/cgi-bin/faq.pl?look=1&id=988622720&n=14

И подумалось мне "Разве совсем никак нельзя сделать ProgressBar, отображающий ход события Query.Open?"....
И начал я думать, денно и ночно думал, и ничего не придумал :))
Решил отдохнуть и тут мне в голову пришла мысль (всего из трех букв :)) UDF.

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

Естественно все ниже сказаное не подходит для пользователей не SQL-серверов. Так же это неподходит для пользователей SQL-серверов которые не поддерживают технологию UDF (кстати я таких серверов незнаю)

Допустим имеется здоровенная таблица и по ней нужно осуществить выборку со сложным условием. Пишем
select fld1, fld2, MyF()
from table
where {сложное условие}

MyF()=UDF которая каким-то хитрым образом (как я незнаю, специализируюсь по другим вопросам, хотя надеюсь если идея понравится специалисты помогут определить способ связи) связывается с клиентом и говорит ему (клиенту), что "Сервер нашел еще одну запись".
Т.к. ни на клиенте, ни на сервере оценить количество записей которые будут отобраны невозможно, то полноценный ProgressBar не получится, но можно отображать статистику типа "Уже отобрано <число записей>". Или можно в функцию передавать параметром допустим, ФИО человека, если в таблице перечислены люди, и тогда клиент сможет показывать нечто типа "Обрабатываю <ФИО>".

Естественно понятно что какой бы ни был способ связи, он будет сильно тормозить SQL-сервер. Возможно стоит сделать так: при загрузке библиотеки UDF она сама загружает другую библиотеку в которой в свою очередь при запуске стартует процесс который и будет выполнять почтовую функцию. А наша UDF будет только вызывать функцию второй библиотеки и передавать ей что "Сервер нашел еще одну запись", и размораживать процесс и завершатся, а наш процесс отправит сообщение клиенту и заснет до нового сообщения.

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

И еще интересно может такой механизм уже гдето используется?

← →
Digitman (2002-09-10 17:34) [1]

Теоретически это возможно.

← →
handra (2002-09-10 17:39) [2]

асинхронный фетчинг у ADO-шных компонентов не пробовал использовать?

← →
Andrey (2002-09-10 17:50) [3]

>handra
Не пробовал..... И вообще я этого реализовывать не пробовал, теоретические выкладки, так сказать.....
Да и я не думаю, что ADO может сказать столько осталось до конца запроса в каком-нибудь (например IB) сервере. Ему (ADO) просто никто не скажет :))

Хотя я как и любой другой могу ошибатся :)

← →
Delirium (2002-09-10 18:00) [4]

>handra
"...асинхронный фетчинг у ADO-шных компонентов..." - событие OnFetchProgress отображает процесс поступления данных, а не процесс исполнения SQL-запроса, запрос может работать минуты и вернуть 10 записей. Так что OnFetchProgress это далеко не выход.

← →
kull (2002-09-10 18:01) [5]

Красивость она завсегда скорость и надежность нагибает...

← →
Fiend (2002-09-10 18:13) [6]

всё что вы описали - это конечно хорошо.
Но самая то соль как раз в том что вы и задачей то не посчитали:
как собсно вы собираетесь угадать как долго будет выполняться запрос?
А ответ юзеру, типа: обрабатываю такого то ФИО ничё может не дать. например если ФИО выбираются без сортировки.

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

ЗЫ: Проверено опытом

← →
Andrey (2002-09-10 18:32) [7]

>Fiend
:) Юзеры и так не жалуются, и без анимашек, да и нет у меня задач в которых запросы больше 3-4 секунд выполняются.

>Бросьте эту идею, мой вам совет!
Повторюсь: "И вообще я этого реализовывать не пробовал, теоретические выкладки, так сказать....."
И добавлю: Может и попробую, но наврядли сильно использовать буду. :)

>как собсно вы собираетесь угадать как долго будет выполняться
>запрос?

Еще раз повторюсь:
"Т.к. ни на клиенте, ни на сервере оценить количество записей которые будут отобраны невозможно, то полноценный ProgressBar не получится"

>обрабатываю такого то ФИО ничё может не дать

Юзеру то ничего не даст, но при свале (чюр меня :)) немного облегчится диагностика.

>kull
>Красивость она завсегда скорость и надежность нагибает...

Угу, как не печально но это так..... Правда я предложил один способ ускорить весь этот процес. Третий абзац снизу :)

← →
Andrey (2002-09-13 14:45) [8]

Появилось маленькое дополнение к идее.

Реализовав не одностороннюю связь "Сервер-->Клиент", а двухстороннюю "Сервер-->Клиент-->Сервер" можно прерывать выполнение хранимых процедур.
Как? Да очень просто. Клиентом посылать нашей второй DLL-ке (которая отвечает за почту) условный сигнал, и она по цепочке через UDF-ку передаст этот условный сигнал в хранимую процедуру, а там его можно и обработать как-нибудь, не только прервать но и сделать чего-нибудь более целесообразное.

P.S. Может статью по нестандартному использованию UDF накатать?
Не, нестоит. Я и стандартно использовать их не очень умею :)

← →
Fiend (2002-09-13 17:01) [9]

Ну для того чтобы прервать выполнение длительных хр.процедур (которые конечно не выглядят ввиде одного селекта) и не нужно никаких библий.

Я например прерываю хп, в которой цикл по огромному курсору, с помощью отдельного соединения с СУБД в моём клиенте. Просто делаю апдейт в специальной табличке. А процедурка периодичесуки делает оттудова неблокируемый селект. Как только поле-флажок, стало равно 0, процедура завершается.

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

← →
Виктор Щербаков (2002-09-13 17:30) [10]

Andrey © (13.09.02 14:45)
Всё это интересно, конечно. Но лучше бы разработчики SQL-серверов позаботились о нормальных механизмах связи сервера с клиентом. А то получается не то что бы через одно место, но так, как будто бы полотном по железу закручивают шурупы.

← →
Игорь Шевченко (2002-09-13 17:43) [11]

← →
evgeg (2002-09-13 17:54) [12]

Для прерывания вып-я процедры в Interbase не нужно наворотов. Достаточно периодически читать в теле процедуры значение генератора, которых устанавливается из программы.

> UDF которая каким-то хитрым образом связывается с клиентом

Вот это самое сложное в вашей идее.

← →
evgeg (2002-09-13 17:55) [13]

Для прогресса можно ис-ть тот же генератор.

Идея по использованию UDF Найти похожие ветки