Вниз
Скачать: CL | DM;

ProgressBar при SQL-запросе.   Найти похожие ветки 

← →
АндрейБ   (2003-02-20 15:58) [0]

Подскажите, как можно определить приблизительное время SQL-запроса. Хотелось бы, чтоб появлялось окно с ProgressBar или что-нибудь вроде этого.


← →
stone ©   (2003-02-20 15:59) [1]

Никак.


← →
Anatoly Podgoretsky ©   (2003-02-20 16:03) [2]

Один раз замерить, результат сохранить и в дальнешим им пользоваться.


← →
АндрейБ   (2003-02-20 16:11) [3]

>Anatoly Podgoretsky
Это не выход, т.к. база постоянно пополняется.

А может можно определить объем выполненного. Или лучше просто выдать сообщение "Ждите..."?


← →
Johnmen ©   (2003-02-20 16:24) [4]

"Ждите..." самое оно !


← →
АндрейБ   (2003-02-20 16:36) [5]

>Johnmen
Спасибо


← →
passm ©   (2003-02-20 16:40) [6]

"Ушла на базу данных..."


← →
Anatoly Podgoretsky ©   (2003-02-20 16:46) [7]

АндрейБ (20.02.03 16:11)
А ты корректируй после каждого запроса.


← →
Виталик   (2003-02-20 17:33) [8]

Т.е. в итоге получится, что при очередном запросе его приблизительное время выполнения будет равно ыремени выполнения предыдущего запроса? В общем-то вариант.


← →
АндрейБ   (2003-02-20 17:35) [9]

Anatoly Podgoretsky (20.02.03 16:46)
Спасибо за вариант, но пока мне, я думаю, будет достаточно просто "ЖДИТЕ"


← →
Desdechado ©   (2003-02-21 10:45) [10]

поставь progressbar, который как только дойдет до конца, начинает сначала. Юзер видит, что не зависли, и ждет :)


← →
Johnmen ©   (2003-02-21 11:01) [11]

>Desdechado © (21.02.03 10:45)

А кто и когда будет ему говорить идти ?


← →
Виталий Панасенко   (2003-02-21 11:02) [12]

В RxLib это есть. Используются callback-функции и пример есть(работает), но у меня ничего не вышло :-(


← →
Anatoly Podgoretsky ©   (2003-02-21 12:04) [13]

Johnmen © (21.02.03 11:01)
Это должно быть в разных потоках.


← →
Johnmen ©   (2003-02-21 12:17) [14]

>Anatoly Podgoretsky © (21.02.03 12:04)
Тогда конечно...Только неясно, как будет инициироваться очередной step прогрессбара...


← →
MsGuns ©   (2003-02-21 12:21) [15]

Для парадокса в свое время мы делали замеры и даже прописали для себя формулу определения веремени ожидания выполнения запроса. Довольно сложная формула, куда входило множество аргументов: кол-во записей в таблице, кол-во выбираемых полей и их длина, наличие индексов, примерный процент (или кол-во) ожидаемых выходных записей и т.д. На связанных запросах коэффициенты как-то хитро перемножались. Самое главное, что получали характеристики, довольно приближенные к реальным затратам времени. Но один минус - все это хорошо работало только на локальном диске. Как только ставилось на сетку, все характеристики летели к черту ;)

И еще. На связанные запросы к таблицам больших размеров (начиная от 1000*5000) ставили порезку на "порции". Результаты были просто ошеломительные. Так при связанном запросе с хотя бы одной неключевой таблицей при объемах данных порядка 5000*50000 записей скорость "порезанного" алгоритма повышалась в СОТНИ раз !
Правда это для 3.5. Для 4-го и более старших эффект был не такой впечатляющий.


← →
Anatoly Podgoretsky ©   (2003-02-21 12:27) [16]

Johnmen © (21.02.03 12:17)
По таймеру, тем более что речь то идет не об абстрактном запросе.



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

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.011 c
1-39381
Спрашивающий
2003-03-03 01:10
2003.03.13
Взаимодействие OpenDialog и функции DiskFree(0)


14-39498
Igorek
2003-02-24 10:46
2003.03.13
Снова про ум человека


1-39369
Lion
2003-02-27 23:21
2003.03.13
QReport перенос строки


14-39505
romychk
2003-02-25 13:40
2003.03.13
FreePascal


3-39169
mate
2003-02-20 15:52
2003.03.13
DBRichEdit и QRRichText




   Наверх