Графическое представление открытия запроса

← →
vvh (2006-05-06 15:42) [0]

Здравствуйте Мастера!
Как визуально показать ход получения данных с сервера, например с помощью ProgressBar.
Используютcя компоненты FibPlpus

← →
ANB © (2006-05-06 15:45) [1]

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

← →
vvh (2006-05-06 15:54) [2]

У меня обычный запрос на выборку данных, открываю его:
tAbon.Open;
И вот необходимо что бы процесс получения записей отображался в ProgressBar.

← →
MsGuns © (2006-05-06 15:55) [3]

С помощью прогресбара - никак. А вот если изменить вид курсора (например, вместо crDefault выставить на время выполнения запроса crHourGlass) и в статусной панельке написать чт-то вроде "Чтение (обновление) данных с сервера БД..", то юзеру можно ясно дать понять, что прога вообще-то не висит ;)

← →
Sergey Masloff (2006-05-06 15:56) [4]

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

← →
vvh (2006-05-06 16:02) [5]

А если перед откытием, получить количество записей в таблице:
select COUNT(id_abon) ....
Ну а потом что-то сделать.

← →
-SeM- (2006-05-06 16:11) [6]

Если только через хранимые процедуры и эвенты... Но оно того стоит?

← →
Nikolay M. © (2006-05-06 16:11) [7]

> Тем, кто утверждает, что невозможно

Читайте вопрос, автору не нужен процесс выполнения запроса, ему нужен процесс получения данных :)
Конечно, автор вряд-ли понимает разницу, но отобразить именно получение данных - как два байта переслать :)

← →
vvh (2006-05-06 16:34) [8]

> Конечно, автор вряд-ли понимает разницу, но отобразить именно
> получение данных - как два байта переслать :)

Простите, но я отлично понимаю разницу, поэтому и обратился с вопросом,
и если не трудно, то подскажите, пожалуйста, как это сделать. Спасибо.

← →
evvcom © (2006-05-06 16:56) [9]

Выбери себе интервал, например, 1 секунда, динамично? И прибавляй по 1% (5%, 10%) в прогресс-баре. Если данные пришли раньше, то прогресс сразу на 100%! Если дошел до 100%, а данных еще нет, то 2 пути: либо прогресс на 0 и сначала, либо начать считать в обратную сторону! :-)))))

← →
ANB © (2006-05-06 17:08) [10]

> vvh (06.05.06 16:34) [8]

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

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

← →
Sergey Masloff (2006-05-06 17:08) [11]

Да мультяшку просто показывать да и все.

← →
ANB © (2006-05-06 17:09) [12]

> сколько из них всего.

= сколько их всего.

← →
vvh (2006-05-06 19:39) [13]

> Грабля третья - собственно передача данных обычно идет очень
> быстро (если ты выбираешь слишком много данных - то это
> плохо спроектировано приложение).
>

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

← →
Anatoly Podgoretsky © (2006-05-06 20:42) [14]

Ход получения данных с сервера - это передача данных, она не включает в себя время выполнения запроса, которое непредсказуемо.

← →
Johnmen © (2006-05-06 20:48) [15]

> Nikolay M. © (06.05.06 16:11) [7]
> Конечно, автор вряд-ли понимает разницу, но отобразить именно
> получение данных - как два байта переслать :)

Если можно, поподробнее. Мне тоже интересно. Именно в разрезе прогрессбара...

← →
Nikolay M. © (2006-05-10 11:07) [16]

> Johnmen © (06.05.06 20:48) [15]
> Если можно, поподробнее. Мне тоже интересно. Именно в разрезе
> прогрессбара...

Во-первых, я имел ввиду, что наблюдать ход фетча данных - реальная задача, в отличие от собственно выполнения запроса сервером.
Во-вторых, я ни разу не работал с FIB+, могу судить только по чужому опыту
http://www.sql.ru/forum/actualthread.aspx?tid=441

← →
Desdechado © (2006-05-10 11:12) [17]

vvh (06.05.06 19:39) [13]
>> если ты выбираешь слишком много данных - то это плохо спроектировано приложение
> как спроэктирована база - это вопрос другой
как видно, ты не понимаешь разницы между проектированием БД и проектированием приложения
приложение, достающее сразу много данных, достойно корзины и не более
юзер не в состоянии просмотреть (и тем паче проанализировать) более 200 строк
значит, надо ему дать возможность уточнить, что он хочет, и только после этого формировать запрос на данные

← →
Sergey13 © (2006-05-10 11:16) [18]

2[17] Desdechado © (10.05.06 11:12)
> приложение, достающее сразу много данных, достойно корзины и не более
Не всегда, но в большинстве случаев.

← →
Desdechado © (2006-05-10 11:21) [19]

> Не всегда, но в большинстве случаев
фразы типа "вообще-то нельзя, но если очень хочется, то можно" я бы оставил для продвинутых, к коим автор вопроса пока не относится
поэтому я столь категоричен

← →
Nikolay M. © (2006-05-10 11:30) [20]

> Desdechado © (10.05.06 11:12) [17]
> приложение, достающее сразу много данных, достойно корзины
> и не более

Жаль, что пользователи филиалов (например), периодически синхронизирующие свои справочники с головным офисом по модемному каналу, этого не знают.

← →
Desdechado © (2006-05-10 11:44) [21]

Nikolay M. © (10.05.06 11:30) [20]
Жаль, что программисты, пишущие "синхронизилки" для пользователей филиалов, этого не знают. Особенно жаль модемщиков, терзающих канал ненужными данными.
И, кроме того, синхронизация справочников не есть нормальный рабочий момент, это сервисная процедура, которая, по хорошему, должна выполняться автоматически и не часто.

← →
Nikolay M. © (2006-05-10 11:56) [22]

> Desdechado © (10.05.06 11:44) [21]

Случаи разные бывают. За все поручишься?

> [17] Desdechado © (10.05.06 11:12)
> приложение, достающее сразу много данных, достойно корзины
> и не более
> юзер не в состоянии просмотреть (и тем паче проанализировать)
> более 200 строк

Сорри, что я на тот же мозоль :)

Все-таки, скажу, что тут зависит от способа визуализации этих данных. Конечно, Грид с тысячами записей это жутко. Но не гридом единым жив человек :) У меня, например, данные представляются графически, в виде объектов на карте. Их там хоть пятдесят тыщ выводи — всё прекрасно анализируется и воспринимается.

Хотя с [19] согласен.

Джо © (10.05.06 12:50) [24]
про карту согласен, сам пользуюсь, но здесь есть один отличительный аспект
эти данные должны восприниматься именно в комплексе, а по одиночке они бессмысленны
хотя и там есть неявная фильтрация
когда пользователь выбирает некий район города, незачем тянуть на клиента другие районы
а когда он смотрит на город целиком, на экране даже в виде точек эти объекты могут не поместиться, посему они там бессмысленны

2[25] Desdechado © (10.05.06 12:59)
Не все закачанное надо обязательно визуализировать. Например я бы наверное предпочел в системе "а-ля кассовый аппарат" закачать 1 раз весь справочник товаров из 10000 записей, чем 10000 раз в течении дня лазить в БД.

Sergey13 © (10.05.06 13:06) [26]
возможны варианты
может, аппарату памяти на все не хватит, или в течение дня ассортимент в БД меняется

← →
vvh (2006-05-11 00:10) [28]

Уважаемые собеседники! Я благодарен Вам за заочный анализ моих способностей, а также за ценные советы(серйозно), но хотелось бы все таки получить более конкретный ответ на мой вопрос, если можно с примером. Спасибо!

> но хотелось бы все таки получить более конкретный ответ
> на мой вопрос, если можно с примером. Спасибо!

Вот так так... Ветку читать не пробовал?

← →
vvh (2006-05-11 09:33) [30]

Ветку я читал, согласен - нет смысла тянуть сразу все 6500 записей, пускай будет 200, ссылку смотрел, но там только вопрос, без ответа.

> [30] vvh (11.05.06 09:33)
> Ветку я читал, согласен - нет смысла тянуть сразу все 6500
> записей, пускай будет 200, ссылку смотрел, но там только
> вопрос, без ответа.

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

Обрати внимание на VCL Apollon там есть такой пример

Графическое представление открытия запроса Найти похожие ветки