Можно ли узнать сколько записей в SQL запросе во время его вып..?

← →
Sirus (2002-05-08 08:14) [0]

Привет мастерам...
Есть вопрос: Можно ли узнать сколько записей уже считано в SQL запрос во время его выполнения???
У меня запрос на выборку выполняется страшно долго... Хотелось бы сделать ProgressBar только вот неизвестно сколько процентов работы выполнено...

With best regards Sirus

← →
Oleg_er (2002-05-08 08:37) [1]

используй ADOQuery

← →
Oleg_er (2002-05-08 08:44) [2]

savva © (27.04.02 09:08)
Если использовать компоненты TADOQuery, то там есть событие OnFetchProgress
procedure Tdata.qryPodTemaFetchProgress(DataSet: TCustomADODataSet;
Progress, MaxProgress: Integer; var EventStatus: TEventStatus);
begin

end;

что к чему - сам разберешься, там все понятно...

← →
Sirus (2002-05-08 09:16) [3]

Я по моему неправильно поставил вопрос...
Надо узнать сколько записей уже считано в запрос TQuery...
Текст запроса: SELECT * FROM SUBS_DATA
Записей в таблице около 500000...
Чтобы юзер не скучал во время открытия запроса, ему нужен прогрессбар...
Вопрос: Как все это реализовать???

← →
Reindeer Moss Eater (2002-05-08 09:19) [4]

Когда скучающий юзер получит хотя бы десятую часть всех 500000 записей, он начнет скучать еще сильнее

← →
Сергей Иванов (2002-05-08 10:34) [5]

В BDE есть структура DBIQryProgress. Попробуй там покопаться.

← →
Reindeer Moss Eater (2002-05-08 10:40) [6]

Если даже узнать сколько записей зафетчено, то как реализовать прогресс бар?
Очень часто сам сервер не знает сколько записей будет в рекордсете после выполнения запроса. Про клиента я уже не говорю.
Как выстваить максимальное значение прогресса?

← →
Johnmen (2002-05-08 10:52) [7]

Полноценно нереализуемо...

← →
+aaZ (2002-05-08 11:24) [8]

2 Johnmen:
Я смотрю, ты умнее всех ... на словах, а на деле не хватает тебя ответить?

← →
Johnmen (2002-05-08 11:28) [9]

>+aaZ (08.05.02 11:24)

За что такие обидки ? По-моему, я четко ответил на поставленный вопрос...

← →
Reindeer Moss Eater (2002-05-08 11:38) [10]

Если это был ответ на мой вопрос, то прошу прощения за двусмысленность.
Я конечно же не спрашивал как выставить максимальное значение.
Я просто хотел сказать, что по-русски это называется "баловство" (то что хочет Sirus)

← →
Johnmen (2002-05-08 11:45) [11]

>Reindeer Moss Eater (08.05.02 11:38)
Это был ответ на вопрос Автора ветки...

>Я просто хотел сказать, что по-русски это
>называется "баловство" (то что хочет Sirus) - вот именно...

>Reindeer Moss Eater (08.05.02 10:40) - Никак...

← →
kaif (2002-05-08 13:39) [12]

А что значит запрос выполняется долго?

1.Долго выполняется сам запрос до первого Fetch
2.Долго выкачиваются данные при помощи Fetch.

В 1-м случае надо найти способ ускорить запрос (грамотно построить базу, проиндексировать поля, используемые в объединении и т.п.)
Во 2-м случае можно не делать сразу Fetch всех записей, а максимальное кол-во записей можно узнать предварительно с помощью другого запроса, что-то вроде SELECT COUNT(*)... с ограничениями, соответствующими ограничениям первого запроса.

← →
Johnmen (2002-05-08 13:49) [13]

>kaif © (08.05.02 13:39)

Если быть абсолютно точным, то SELECT COUNT(*)... не поможет, т.к. между ним и содержательным запросом может измениться количество записей, напр.др.юзером....

← →
Reindeer Moss Eater (2002-05-08 13:54) [14]

> kaif
У человека юзер скучал ожидая результаты одного запроса, теперь ему предлагают сначала дождаться Select Count,
потом смотреть на прогрессбар с отображением основного запроса и все для того чтобы потом выяснилось что "в это время в замке" другой юзер сделал Truncate этой таблице.

← →
kaif (2002-05-08 14:06) [15]

SELECT COUNT(*) я предлагал для случая, когда сам запрос быстрый, а Fetch-ей много. Потом для ProgressBar.Max можно иметь и приблизительное кол-во записей. в конце концов, можно открыть транзакцию repeatable read (snapshot).
Я не предлагаю все это, как выход. Но иногда рассмотрение всех альтернатив позволяет легче примириться с тем, что есть или создать эрекцию для улучшения общей логики.
Зачем качать 500тыс. записей на клиент? Если для последующей печати или записи в файл, к примеру, то тут возможны варианты умных решений.
А если для просмотра, то зачем из вообще скачивать? Кто это смотреть будет?
Если для математической обработки, то может лучше все это на сервере организовать при помощи всяких ХП и UDF?

← →
Johnmen (2002-05-08 14:13) [16]

← →
Sirus (2002-05-08 14:44) [17]

Всем спасибо за участие в дискуссии... (моем баловстве) :)))
Но это было ничуть не баловство... просто была такая проблемка..
А решил проблему я без всяких ПрогрессБаров...
Попросту сделал бегущую строку которая бегает туда сюда...
Юзеру понравилось... А 500000 записей нужны были для подсчета...
Причем скажем 157234 запись напрямую зависела от 1657 записи...
А 1657 запись в свою очередь зависела от 461905 записи... и вот так до конца... то есть запрос должен был делиться еще на много маленьких запросиков... И нечего советовать...
просто скажите подтип Johnmen"a
> Полноценно нереализуемо...

With best regards Sirus...
P.S. Я вовсе не баловень

Можно ли узнать сколько записей в SQL запросе во время его вып..? Найти похожие ветки