![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Графическое представление открытия запроса [D7, FireBird1.5]
vvh © (2006-05-06 15:42:00)Здравствуйте Мастера!
Как визуально показать ход получения данных с сервера, например с помощью ProgressBar.
Используютcя компоненты FibPlpus
Fhunt (2006-05-12 04:07:00) [1]Обрати внимание на VCL Apollon там есть такой пример
Джо (2006-05-11 15:09:00) [2]> [30] vvh (11.05.06 09:33)
> Ветку я читал, согласен - нет смысла тянуть сразу все 6500
> записей, пускай будет 200, ссылку смотрел, но там только
> вопрос, без ответа.
Я не о том. А о том, что уже, кажется, несколько раз говорили, что обработка запроса и получение его результатов — процесс, так сказать, недискретный с точки зрения клиента.
vvh (2006-05-11 09:33:00) [3]Ветку я читал, согласен - нет смысла тянуть сразу все 6500 записей, пускай будет 200, ссылку смотрел, но там только вопрос, без ответа.
Джо (2006-05-11 01:47:00) [4]> но хотелось бы все таки получить более конкретный ответ
> на мой вопрос, если можно с примером. Спасибо!
Вот так так... Ветку читать не пробовал?
vvh (2006-05-11 00:10:00) [5]Уважаемые собеседники! Я благодарен Вам за заочный анализ моих способностей, а также за ценные советы(серйозно), но хотелось бы все таки получить более конкретный ответ на мой вопрос, если можно с примером. Спасибо!
Desdechado (2006-05-10 13:08:00) [6]Sergey13 © (10.05.06 13:06) [26]
возможны варианты
может, аппарату памяти на все не хватит, или в течение дня ассортимент в БД меняется
Sergey13 (2006-05-10 13:06:00) [7]2[25] Desdechado © (10.05.06 12:59)
Не все закачанное надо обязательно визуализировать. Например я бы наверное предпочел в системе "а-ля кассовый аппарат" закачать 1 раз весь справочник товаров из 10000 записей, чем 10000 раз в течении дня лазить в БД.
Desdechado (2006-05-10 12:59:00) [8]Джо © (10.05.06 12:50) [24]
про карту согласен, сам пользуюсь, но здесь есть один отличительный аспект
эти данные должны восприниматься именно в комплексе, а по одиночке они бессмысленны
хотя и там есть неявная фильтрация
когда пользователь выбирает некий район города, незачем тянуть на клиента другие районы
а когда он смотрит на город целиком, на экране даже в виде точек эти объекты могут не поместиться, посему они там бессмысленны
Джо (2006-05-10 12:50:00) [9]> [17] Desdechado © (10.05.06 11:12)
> приложение, достающее сразу много данных, достойно корзины
> и не более
> юзер не в состоянии просмотреть (и тем паче проанализировать)
> более 200 строк
Сорри, что я на тот же мозоль :)
Все-таки, скажу, что тут зависит от способа визуализации этих данных. Конечно, Грид с тысячами записей это жутко. Но не гридом единым жив человек :) У меня, например, данные представляются графически, в виде объектов на карте. Их там хоть пятдесят тыщ выводи — всё прекрасно анализируется и воспринимается.
Хотя с [19] согласен.
Desdechado (2006-05-10 12:06:00) [10]Nikolay M. © (10.05.06 11:56) [22]
см. Desdechado © (10.05.06 11:44) [19]
Nikolay M. (2006-05-10 11:56:00) [11]
> Desdechado © (10.05.06 11:44) [21]
Случаи разные бывают. За все поручишься?
Desdechado (2006-05-10 11:44:00) [12]Nikolay M. © (10.05.06 11:30) [20]
Жаль, что программисты, пишущие "синхронизилки" для пользователей филиалов, этого не знают. Особенно жаль модемщиков, терзающих канал ненужными данными.
И, кроме того, синхронизация справочников не есть нормальный рабочий момент, это сервисная процедура, которая, по хорошему, должна выполняться автоматически и не часто.
Nikolay M. (2006-05-10 11:30:00) [13]
> Desdechado © (10.05.06 11:12) [17]
> приложение, достающее сразу много данных, достойно корзины
> и не более
Жаль, что пользователи филиалов (например), периодически синхронизирующие свои справочники с головным офисом по модемному каналу, этого не знают.
Desdechado (2006-05-10 11:21:00) [14]> Не всегда, но в большинстве случаев
фразы типа "вообще-то нельзя, но если очень хочется, то можно" я бы оставил для продвинутых, к коим автор вопроса пока не относится
поэтому я столь категоричен
Sergey13 (2006-05-10 11:16:00) [15]2[17] Desdechado © (10.05.06 11:12)
> приложение, достающее сразу много данных, достойно корзины и не более
Не всегда, но в большинстве случаев.
Desdechado (2006-05-10 11:12:00) [16]vvh (06.05.06 19:39) [13]
>> если ты выбираешь слишком много данных - то это плохо спроектировано приложение
> как спроэктирована база - это вопрос другой
как видно, ты не понимаешь разницы между проектированием БД и проектированием приложения
приложение, достающее сразу много данных, достойно корзины и не более
юзер не в состоянии просмотреть (и тем паче проанализировать) более 200 строк
значит, надо ему дать возможность уточнить, что он хочет, и только после этого формировать запрос на данные
Nikolay M. (2006-05-10 11:07:00) [17]
> Johnmen © (06.05.06 20:48) [15]
> Если можно, поподробнее. Мне тоже интересно. Именно в разрезе
> прогрессбара...
Во-первых, я имел ввиду, что наблюдать ход фетча данных - реальная задача, в отличие от собственно выполнения запроса сервером.
Во-вторых, я ни разу не работал с FIB+, могу судить только по чужому опыту
http://www.sql.ru/forum/actualthread.aspx?tid=441
Johnmen (2006-05-06 20:48:00) [18]
> Nikolay M. © (06.05.06 16:11) [7]
> Конечно, автор вряд-ли понимает разницу, но отобразить именно
> получение данных - как два байта переслать :)
Если можно, поподробнее. Мне тоже интересно. Именно в разрезе прогрессбара...
Anatoly Podgoretsky (2006-05-06 20:42:00) [19]Ход получения данных с сервера - это передача данных, она не включает в себя время выполнения запроса, которое непредсказуемо.
vvh (2006-05-06 19:39:00) [20]
> Грабля третья - собственно передача данных обычно идет очень
> быстро (если ты выбираешь слишком много данных - то это
> плохо спроектировано приложение).
>
У меня абонентская программа, нужно вытянуть всех абонентов, сейчас их около 6500, кроме того, у каждого есть адрес и т.д. поэтому как спроэктирована база - это вопрос другой.
Тем неменее, Спасибо!!! всем кто ответил, есть повод для размышлений, и некоторые идеи можно использовать.