Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2005.07.31;
Скачать: CL | DM;

Вниз

Запрос и 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 будет моментальный


 
Mike Kouzmine ©   (2005-06-14 17:13) [32]

Digitman ©   (10.06.05 12:51) [1] Можно, через генератор.


 
Sergey13 ©   (2005-06-15 09:34) [33]

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


 
Mike Kouzmine ©   (2005-06-15 16:29) [34]

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


 
Johnmen ©   (2005-06-15 17:59) [35]

>Mike Kouzmine ©   (14.06.05 17:13) [32]

Один недостаток (как уже говорилось) - не узнать заранее размер стакана.


 
Zacho ©   (2005-06-15 19:38) [36]

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]
Он ведь истинную правду сказал :)


 
Mike Kouzmine ©   (2005-06-15 20:21) [37]

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


 
Mike Kouzmine ©   (2005-06-15 20:29) [38]

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


 
Zacho ©   (2005-06-15 20:45) [39]

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


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


 
Zacho ©   (2005-06-15 21:24) [40]

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


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

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



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

Текущий архив: 2005.07.31;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.048 c
1-1121315291
jcrush
2005-07-14 08:28
2005.07.31
RSS XMLDoc не обновляется :(


14-1121158662
alless
2005-07-12 12:57
2005.07.31
Microsoft = 666?


11-1104228577
AlexandrK
2004-12-28 13:09
2005.07.31
KOLEDB: OLE DB error


5-1090854143
sirin
2004-07-26 19:02
2005.07.31
ActiveX Control


6-1113826059
Alexis
2005-04-18 16:07
2005.07.31
Проблема с send()/recv() в многопоточной программе