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

Вниз

Прогрес выполнения процедуры   Найти похожие ветки 

 
Kombat   (2002-07-21 12:03) [0]

Hi All! Есть процедура которая производит изменения в БД, процесс идет примерно 10 минут. Хотелось бы показате пользователю что он не завис)). Переносить всю логику в программу только из-за визуализации прогреса не хочется, замедлится работа. Какие есть методы отображения прогреса. Я думал об возможности использования генераторов (в процедуре увеличиваем его значение, а из программы читаем), но тогдакак наилучшим образом снимать значания генератора из программы, не хотелось бы завалить сервер постоянными SELECT GEN_ID ...
Какие есть еще пути решения этой проблемы?
Заранее благодарен.


 
Lola   (2002-07-21 12:13) [1]

Можно вставить какой-нибудь компонент с анимацией. По-моему, это для 10 минут достаточно щадащий вариант.


 
Kombat   (2002-07-21 12:24) [2]

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


 
kaif   (2002-07-21 14:24) [3]

У меня возникла внезапная идея!
Я никогда так не делал, но это может оказаться гениально...
Сделай в своей хранимой процедуре SUSPEND и возвращай какое- нибудь увеличивающееся число:

CREATE PROCEDURE MY_HEAVY_PROCEDURE(...)
RETURNS(PROGRESS INTEGER)
AS
BEGIN
.... <Всякие тяжелве дела>
Иногда среди них:
IF <некое условие, например, шаг в 1000 записей> THEN
BEGIN
PROGRESS = PROGRESS + 1;
SUSPEND;
END
END

Теперь запускаешь свою тяжелую процедуру не с помощью
EXECUTE PROCEDURE MY_HEAVY_PROCEDURE,
а с помощью:
SELECT PROGRESS FROM MY_HEAVY_PROCEDURE
Процедура начинает просто медленно возвращать набор прогресса.
По-моему это сумасшедшая идея. Главное, IB это позволяет легко сделать.
Каждый следующий FETCH со стороны клиента сделает Update прогресс-бара. Процесс останется однопоточным, как ты хочешь и живым одновременно.
Я сейчас сам побегу такое попробую...
С уважением.


 
Kombat   (2002-07-21 14:32) [4]

to kaif © прикольно. надо начинать пробовать такой вариант, может действительно получится. Спасибо.

Но другие варианты тоже еще принимаются.


 
kaif   (2002-07-21 14:38) [5]

Для того, чтобы клиент выбирал один fetch за другим нужно сделать что-то вроде:

with MyHeavyProcQuery do
begin
Open;
while not Eof do
begin
ProgressBar.Position := FieldByName("PROGRESS").AsInteger;
Next;
end;
end;


 
kaif   (2002-07-21 14:42) [6]

Более того. У меня еще идея. Если процедура будет возвращать не только PROGRESS, но и STATUS_MESSAGE VARCHAR(100), то можно будет извещать пользователя текстовыми сообщениями о этапах исполнения процедуры, чтобы если она рухнет или зависнет, тот знал, на где именно это произошло...
Отображать процесс можно даже не в ProgressBar в этом случае, а в Grid-е. Смотреться должно великолепно.


 
Kombat   (2002-07-21 14:45) [7]

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


 
kaif   (2002-07-21 14:48) [8]

Но это же редко будет происходить! Допустим, раз в 10 сек. Я уверен, что на скорость это никак не повлияет. Сервер с клиентом взаимодействуют очень быстро (по сравнению с временем работы такой тяжелой процедуры). Нужно пробовать, конечно.


 
Kombat   (2002-07-21 14:56) [9]

да, нужно пробовать, этим и займусь.
Это, во всяком случае, красивое решение, то что встречалось ранее сводилось к "ищи в IB API" - а твое должно по идее работать на любом сервере БД


 
kaif   (2002-07-21 16:36) [10]

Насчет того, что под любым сервером сработает, я бы не спешил так думать. SUSPEND - фишка IB.
В любом случае сообщи, что получилось. Мне тоже интересно.


 
Kombat   (2002-07-21 19:25) [11]

к сожалению не все получается как хотелость ((. Когда делаем Open IBQuery в проге, то отображение данных (прогрес процедуры) начинается после выполнения всей процедуры, т.е. после выполнения действий. А нужно чтоб после кажного suspend. Может я конечно что-то не так делаю, но помоему Open передаст данные Гриду после полного открытия


 
Opuhshii   (2002-07-22 10:05) [12]

Используй генератор,.. ему не нужно Transaction Commit для изменения значения,... и соответственно через определенное время получаешь значения этого генератора,.. imho...


 
Desdechado   (2002-07-22 10:19) [13]

2 kaif © (21.07.02 14:24)
> У меня возникла внезапная идея!
На самом деле идея не нова, но она не работает. Fetch начинается только ПОСЛЕ выполнения запроса, т.е. после создания сервером курсора для результата выборки.
Вариант с анимацией проще, хотя он и не показывает истинного прогресса операции, поскольку сервер сам не знает, сколько времени у него это займет.


 
kaif   (2002-07-22 14:06) [14]

2 Desdechado © (22.07.02 10:19)
>Fetch начинается только ПОСЛЕ выполнения запроса
Жаль. Хотя у меня было такое опасение.
Тогда остается генератор + events (может быть)
или анимация.
Хотя я бы все-же посмотрел логику. Не стоит 10-20 мин. вещи запускать, ИМХО. Что-то в организации базы (самой задачи) не так... Если всего 70 тыс записей. Не миллионы же.


 
kombat   (2002-07-22 16:12) [15]

70 тыс обрабатываются 3 минуты, но в другой задаче будет 1,5 млн., что на много больше. Пока работаем без визуализации прогреса, а потом буду пробовать вариант с генератором. Евент не пройдет так как он тоже работает в контексте транзакции.


 
AlexSam   (2002-07-22 16:56) [16]

А процедура состоит из одного инсерта и т.д. или это набор инсертов или вообще курсор?


 
kombat   (2002-07-22 17:27) [17]

это, в полном варианте набор процедур которые идут одна за другой (некоторые в IB, а те что нельзя реализовать по причине недостатка язиковых средств IB - в делфях). Это закрытие месяца в телекоммуникационной компании. Большинство процедур имеют такой вид - формируется таблица (условно): абонент-данные... Потом на основании этой таблицы производятся выборки, обновления и добавления в другие таблицы (начисления, счета и пр.). Большие таблицы - это трафик за месяц.
Кстати, может у кого есть опыт по написанию прог для телекоммуникаций? дайте контакт, может опытом обменяемся?


 
AlexSam   (2002-07-22 17:32) [18]

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


 
kombat   (2002-07-22 17:35) [19]

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


 
Alexandr   (2002-07-23 08:11) [20]

а ночь для кого придумали?


 
AlexSam   (2002-07-23 09:40) [21]

А может, имеет смысл поколотить объемы обраратываемых данных на несколько в XP?


 
il   (2002-07-23 09:51) [22]

Я согласен с AlexSam.
Надо после выполнения очередной операции куда-нибудь писать что-то вроде "Отработала проца такая-то". И каждый раз читать это и выводить в грид. Думаю, что по сравнению с 10 минутами работы это будут небольшие потери времени. А если произойдет ошибка, то опять же ее можно будет вывести юзверю, короче, вести обычный протокол. К тому же можно добавить возможность контролировать процесс - остановить и возобновить. А анимация - это полумера, украшательство и не более.


 
Desdechado   (2002-07-23 10:13) [23]

> а ночь для кого придумали?
во-во, и я о том же :)

> я сейчас в данном варианте вообще все в делфях обработываю.
дык, конечно, время выполнения на ПОРЯДОК больше при таком подходе. ты все в процедуру затолкай и почувствуй разницу



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

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

Наверх





Память: 0.63 MB
Время: 0.054 c
3-35185
***
2002-07-23 11:29
2002.08.12
форматирование целого типа


14-35437
Malder
2002-07-13 01:59
2002.08.12
Когда же форум доделают ?


1-35288
alex_vas
2002-07-29 13:39
2002.08.12
ListView. Проблемы - фильтрация и скорость


14-35430
Wild Wizard
2002-07-17 10:30
2002.08.12
Я тоже поступил


4-35511
Prooksius
2002-06-06 10:41
2002.08.12
RichEdit 1.0 vs RichEdit 2.0





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский