Запрос и ProgressBar

← →
Dummes (2005-06-10 12:49) [0]

Посоветуйте как ослеживать время выполнения SQL-запросов с отображением в ProgressBar.

Dummes

← →
Digitman © (2005-06-10 12:51) [1]

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

← →
Sergey13 © (2005-06-10 12:55) [2]

2 Dummes (10.06.05 12:49)
Отслеживай начало и конец. Между ними - хоть прогресбар хоть авишку крути - одинаково информативно. 8-)

← →
rh (2005-06-10 12:55) [3]

а разве только IB не может?

← →
Digitman © (2005-06-10 12:58) [4]

> rh (10.06.05 12:55) [3]

никто не может.
но у автора фигурирует конкретно IB

← →
Dummes (2005-06-10 13:11) [5]

Совсем печально и грусно стало..

Отслеживай начало и конец. Между ними - хоть прогресбар хоть авишку крути - одинаково информативно. 8-)
Получить Count можно, а как к нему «инкрементировать»?

← →
Digitman © (2005-06-10 13:15) [6]

> Получить Count можно

нельзя.

пока запрос не будет выполнен сервером, нит о каком Count и речи идти не может.

более того, в ряде случаев и после исполнения запроса Count не будет доступен до тех пор пока не сходишь в конец НД

← →
Dummes (2005-06-10 13:19) [7]

Благодарю.

← →
Dummes (2005-06-14 10:06) [8]

Что еще можно предпринять. Посоветуйте.

← →
Digitman © (2005-06-14 10:12) [9]

← →
paul_k © (2005-06-14 10:16) [10]

1. Оптимизировать запрос, чтоб не надо было показывать юзеру сколько сигарет он ещё может выкурить.
2. Оптимизировать структуру БД
3. перейти к пункту 1

Перед началом исполнения запроса начать крутить картинку после его исполнения прекратить оное действие

← →
Anatoly Podgoretsky © (2005-06-14 10:16) [11]

Dummes (14.06.05 10:06) [8]
А ничего не надо предпринимать, поскольку недостижимо.

← →
КиТаЯц © (2005-06-14 10:17) [12]

Лично я просто курсор мыши меняю. Что-то типа...
Screen.cursor:= MyCursor; SQL.Run; Screen.cursor:= crDefoult;

← →
Val © (2005-06-14 10:19) [13]

> [12] КиТаЯц © (14.06.05 10:17)
а сам он никак не меняется?

← →
-=XP=- © (2005-06-14 10:22) [14]

Сделать к в NN - бегающий туда-сюда ProgressBar.
Взять приблизительно максимальное время выполнения запроса, например, 5 сек. И "накручивать" ProgressBar от минимума к максимуму в течение этих 5 сек. Для пущей убедительности можете добавить "рывков" и "притормаживаний". Если запрос к этому времени не закончен - начать откручивать PrograssBar назад, от максимума к минимуму. В принципе - ничем не лучше анимации.
Если пользователи на такую уловку поймаются - Вам повезло. Если же не поймаются - ... ;)

← →
msguns © (2005-06-14 10:22) [15]

>КиТаЯц © (14.06.05 10:17) [12]
>SQL.Run;
Screen.cursor:= crDefoult;

Это по-китайски ?

← →
КиТаЯц © (2005-06-14 10:26) [16]

>msguns © (14.06.05 10:22) [15]
:)))
Я же написал: "Что-то типа..."

← →
Dummes (2005-06-14 10:35) [17]

А если поставить счетчик (FireBIRD) в ХП и через Suspend отслеживать? А перед этим вычислить Count...

← →
Anatoly Podgoretsky © (2005-06-14 10:37) [18]

Какой настойчивый парень.

← →
Digitman © (2005-06-14 10:40) [19]

> через Suspend отслеживать

самый первый Suspend отработает уже после того как НД будет сформирован

← →
msguns © (2005-06-14 10:43) [20]

>Dummes (14.06.05 10:35) [17]
>А если поставить счетчик (FireBIRD) в ХП и через Suspend отслеживать? А перед этим вычислить Count...

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

← →
Sergey13 © (2005-06-14 10:46) [21]

2[17] Dummes (14.06.05 10:35)
А что зависит от точности прорисовки ПрогресБара? Даже если тебе удастся (это вряд ли (с) т. Сухов), то одинаковое количество записей одного и того же запроса может возвращвться за время, отличающееся на прорядки. Смысл то какой в этом?

ЗЫ: Надо стараться писАть так, что бы работало быстро, а не показывать как медленно работает.

← →
msguns © (2005-06-14 10:51) [22]

>Sergey13 © (14.06.05 10:46) [21]
>ЗЫ: Надо стараться писАть так, что бы работало быстро, а не показывать как медленно работает.

Дык эта.. Ежели первое-то не выходит, что остается-то ? Правильно - работать над вторым ;)

← →
Dummes (2005-06-14 10:53) [23]

Запросы оптимизированны. Хотелось совершенства.
Всем спасибо.

← →
Sergey13 © (2005-06-14 10:57) [24]

2[17] Dummes (14.06.05 10:35)
Может просто поменьше записей возвращать надо? Может сервак мгновенно отдает, а по сетке долго тянется.

← →
Sergey13 © (2005-06-14 10:59) [25]

2[23] Dummes (14.06.05 10:53)
>Запросы оптимизированны.
ИМХО, это слишком оптимистическое заявление. 8-)
Редко встречаются запросы, которые нельзя бы было улучшить. Разве что
select * from table. 8-)

← →
Lexer © (2005-06-14 10:59) [26]

Dummes, поюзай TDBProgressBar из RX.

← →
Dummes (2005-06-14 11:02) [27]

Dummes, поюзай TDBProgressBar из RX.

А смысл юзать?
Проблемма Max и приращения остается...Увы.

← →
Dummes (2005-06-14 12:42) [28]

А вот что нашел в литературе:FetchProgress (RecordsetEvent) Method

This method is called periodically during a lengthy asynchronous operation to report how many more rows have currently been retrieved (fetched) into the Recordset.

Syntax

FetchProgress Progress, MaxProgress, adStatus, pRecordset

Parameters

Progress A Long. The number of records that have currently been retrieved by the fetch operation.

MaxProgress A Long. The maximum number of records expected to be retrieved.

adStatus An EventStatusEnum status value.

pRecordset A Recordset object. The object for which the records are being retrieved.

Значит через fetch можно отслеживать?

← →
msguns © (2005-06-14 12:46) [29]

Можно поподробнее про асинхронные операции в ИБ ?

← →
Zacho © (2005-06-14 12:52) [30]

Dummes (14.06.05 12:42) [28]

Вот именно фетч ты и можешь "визуализировать". А выполнение запроса - нет.

msguns © (14.06.05 10:43) [20]
А если сотворить на сервере евент..

Не получится :))) Евенты придут клиенту только после коммита. Все сразу :)
Но нечто анологичное можно сотворить с UDF.

← →
ЮЮ © (2005-06-14 12:53) [31]

>Значит через fetch можно отслеживать?

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

2[32] Mike Kouzmine © (14.06.05 17:13)
>Digitman © (10.06.05 12:51) [1] Можно, через генератор.
Теперь все должны умолять о подробностях? 8-)

Sergey13 © (15.06.05 09:34) [33] А что тут умолять. Все сразу поняли как. Берешь генератор и в хп каждую итерацию фор селект прибавляешь по 1. А клиетн читает.
Кстати, с помощью генератора можно прерывать и выполнение хп.
Поясню. теперь клиент меняет значение генератора, хп каждую итерацию читает, как изменил - выход.

Mike Kouzmine © (15.06.05 16:29) [34]
Берешь генератор и в хп каждую итерацию фор селект прибавляешь по 1. А клиетн читает.

Ну и чем это отличается от цикла
MyDataSet.Open; while not MyDataSet.Eof do begin ... // а здесь мы что-то делаем с прогрессбаром ... MyDataSet.Next; end; на клиенте ?
Правильно, ничем. Намёк понятен ? :)

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

А это - уже другая задача. Кстати, см. Digitman © (14.06.05 10:40) [19]
Он ведь истинную правду сказал :)

Johnmen © (15.06.05 17:59) [35] За все надо платить. :) Плата Select count(*) where ........
Zacho © (15.06.05 19:38) [36] Нет. Не понят. Если база локальная, то да. Иначе нет.

Хотя я сам не пробовал. Скорее всего не прав. Да и обсуждалось выше. Сморозил.

Mike Kouzmine © (15.06.05 20:21) [37]
Нет. Не понят. Если база локальная, то да. Иначе нет.

Не важно, локальная или сетевая. Но новое значение генератора клиент получит только после очередного fetch (т.е. после MyDataSet.Next), а зачем тогда генератор ? То же самое можно сделать и на клиенте, и обычной переменной в ХП.
С "прерыванием запроса" - другое дело. Но, по сути дела, скорее всего это будет "прерыванием фетча", а не запроса. Впрочем, здесь уже я могу ошибаться :)

Zacho © (15.06.05 20:45) [39]
Но новое значение генератора клиент получит только после очередного fetch (т.е. после MyDataSet.Next

Дополню: на самом деле клиент эти значения будет получать "пачками", в зависимости от того, сколько записей выберется за один фетч.
Только что проверил :) И просто запросом, и с ХП. Запрос выбирает примерно 7000 записей. В другом процессе отслеживается значение генератора. В первом делаем DataSet.Open. Во втором процессе видим, что генератор прирос на 400. В первом начинаем делать DataSet.Next. Во втором процессе видим, что некоторое время значение генератора не изменяется, потом (очевидно, первый процесс "затребовал" новую порцию данных) начинает расти. Потом останавливается. И т.д.
Так что отслеживать "прогресс" выполнения запроса с помощью генератора - занятие довольно бессмысленное.

P.S. Приведённые мной цифры довольно условны.

В смысле, "как посылается" ? Обычно, TIBSQL.

Я сделал 2 простеньких тестовых приложения. В одном - запрос, "дергающий" генератор, в другом - запрос, читающий "текущее" значение генератора.

Собственно, моей целью было убедится в том, что генератор будет менять значение именно в результате вызова isc_dsql_fetch, а не isc_dsql_execute2 или isc_dsql_execute. В чём и убедился :)

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

Запрос и ProgressBar Найти похожие ветки