Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Работа с Interbase [D6, IB6.x]


Страницы:   1 2 3

MAxiMum ©   (2002-03-26 12:29:00) 

У меня, вообще-то, куча вопросов по Interbase. Ответьте, хотя бы на некоторые.
1. Как клиент может послать обновлённые (добавленные) данные?
2. Как сервер может узнать об обновлении?
Пока всё. ПОМОГИТЕ!!!


MAxiMum   (2002-03-28 14:10:00) [1]

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


GrayMage   (2002-03-28 14:04:00) [2]

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


MAxiMum   (2002-03-28 13:14:00) [3]

Ну что касается лично меня, то у меня клиентов может и не быть вовсе, а может и 3-4 максимум. Реально - 1-2. Думаю, если переоткрывать всё при обновлении, ничего с ними не случится.
Другое дело, что действительно, переоткрытие может быть плохим помощником, когда пользователь редактирует данные.
Кстати, я придумал, как можно обновлять данные только на всех клиентах, кроме того, кто сделал изменения: послыать сообщение типа: POST_TABLENAME_COMPNAME. Тогда по имени я смогу определить тип события, имя таблицы и имя компьютера.
А зачем нужно BDE? Я лично без него работаю. Связь без алиасов через IBDatabase.


Vladimir_Shk   (2002-03-28 12:06:00) [4]

Вообще я так думаю, данная проблема решается через использование ADO и ServerCursor - Dynamic. Тогда на каждой машине данные будут актуальными. Хотя сами они конечно не перерисовываются, а обновляются при Dataset.Refresh или просто пролистывании содержимого экрана.


Alexandr   (2002-03-28 11:21:00) [5]

на fibplus.com.ua такая статья

а в остальном согласен


Fareader   (2002-03-28 11:17:00) [6]

на Ib.demo.ru был предложен вариант обновления данных на клиентах, без использование событий IB, с помощью дополнительной таблицы, в общем то нелохое решение. А у меня по таймеру обновляются данные на клиентах через каждые 5 минут и нормально, а чтобы не переоткрылось пока чего-то редактируется - выбрасываем флаг и таймер не переоткрывает dataset пока он в редакции, можно это углубить и расширить, но это дело вкуса. вы проблему раздули из ничего я полностью согласен с Alexandr`ом:
"Это не надо в 99% случаев, даже когда сначала кажется, что именно так надо". человек все равно не сможет обработать данные, которые будут ему предлагаться каждую секунду.


Mad_Vad   (2002-03-28 10:51:00) [7]

Ну чего спорить то?

ib.demo.ru

Там Вы найдете все ответы на интересующие Вас вопросы по Interbase/Firebird.


kalex77   (2002-03-28 10:46:00) [8]

А если использовать сервер приложений?
Пусть работа с БД идет через него, а он при минимальной функциональности оповещает клиента об обновлениях.

Кроме нужно подбирать уровень изоляции под свою задачу.


Alexandr   (2002-03-28 10:27:00) [9]

да ничего тут не может измениться.

Такова природа вещей


GrayMage   (2002-03-28 10:18:00) [10]

Когда-то тему обновления поднимали, как я помню ниче путного предложить никто не смог. Думал с появлением 6 Delphi что-то изменилось. А так, единственная правильная мысль в Реальном времени обновлять только самые необходимые данные, остальные только по таймеру совместно с совокупностью 5 - n эвентов или по кнопке.


Alexandr   (2002-03-28 10:12:00) [11]

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


GrayMage   (2002-03-28 10:10:00) [12]

2 Alexandr
При чем тут текущая запись? А если запись не текущая то что?


Alexandr   (2002-03-28 10:06:00) [13]

2Graymage: Задай RefreshSQL для обновления одной записи и обновляй текущую запись командой refresh.
2dymka: вот вот. Тута думать сильно надо.


dymka   (2002-03-28 09:54:00) [14]

Alexandr, браво!
Есть еще вариант - посылать UDP Broadcast всем клиентам, а там при получении сообщений переокрывать набор...
Но я просто представляю ситуация, когда с сервера приходит событие или по сети броадкаст, моя машина вдруг начинает жужжать, клиент подвисает на время... все исчезает, а потом опять появляется, или мигает, или ни с чего курсор становится SQL...
Если нужно делать обновления, то думаю нужно полностью сменить архитектуру системы...
А если кто-то редактирует данные, которые редактируешь ты?
у тебя бац и все на глазах сменится... не... клиент-сервер не для этого создавался... а если условия поменяются работы и нужно будет пару компов поставить на линию DSL??? или еще хуже на модем...


GrayMage   (2002-03-28 09:52:00) [15]

2 Alexandr:

> BDE не умеет обновлять одну запись в dataset, поэтому нужно
> использовать IBX, FIBplus, IBO

То же самое, но по медленнее - как с помощью IBX, FIBplus обновить только одну запись?


Alexandr   (2002-03-28 09:35:00) [16]

если действительно данные у клиентов на экране должны быть постоянно актуальными, тогда

1) Это сделать сложно для разработчика
2) Это не надо в 99% случаев, даже когда сначала кажется, что именно так надо.
3) Это ресурсоемко
4) нужно использовать свой механизм получения информации об изменениях, а не events от Interbase, только тогда можно получить приемлимое качество работы. Реализация этого не такая простая, но без него как правило ничего путнего не получится.
5) BDE не умеет обновлять одну запись в dataset, поэтому нужно использовать IBX, FIBplus, IBO
6) Практически ни одна программа, работающая с базами данных такое не позволяет делать, а если и позволяет, то этим мало кто пользуется из-за тормозов и прочих ограничений.
7) Идеальный вариант-обновление по нажатию на кнопку в программе.


GrayMage   (2002-03-28 09:34:00) [17]

Да знаю я о триггерах и событиях, знаю. И делаю события по максимуму отсекая ненужные для обновления. Но трафик то при этом не снижается! Представь 4-8 компов выписывающих накладные, добавляем позицию - изменяются остатки + изменилась сумма накладной - и представь себе трафик!

Ладно это ерунда - сузим Query до минимума.

Вопрос вот в чем: как обычная BDE работает с таблицами, скажем DBase? Где-то кто-то писал, что она тоже строит Query и каждый раз ее перечитывает? Если это так, то остается одна проблема - как сделать по нормальному так, чтобы у пользователя при изменениях в окне (активном, неактивном) все приложение на некоторое время не подвисало.


MAxiMum   (2002-03-28 08:46:00) [18]

2dymka
Да, обновления нужно видеть сразу. Этого требует моя совесть и это - требования постановщика и заказчика. Это и правильно.
Почему ты подумал, что я буду обновлять данные.
Хорошо, поясню подробнее, клиент меняет запись. Тогда на всех клиентах и сервере данных должны переоткрываться. Это я решил организовать с помощью триггеров и событий. Но я не хочу, чтобы и клиент, сделавший изменения, перечитывал данные.
2GrayMage
Машина узнаёт об изменениях с помощью триггеров и событий.


dymka   (2002-03-28 08:46:00) [19]

Захотять увидеть новое - пусть нажмут кнопку обновить, где и переоткроешь все наборы данных...
Или вешай события на триггеры, раз уж очень важно следить за изменениями...


GrayMage   (2002-03-28 07:56:00) [20]

2 dymka:
Обоснование: выписывание накладных при отпуске товара.
Отдел 1: на 4 - 8 компах выписывают эти накладные - в реальном времени меняются остатки - количество позиций небольшое, порядка 15 000 - 20 000 (при запросе сужаю диапазон переноса остатков до текущей группы).
Отдел 2: Менеджер склада (обязанности: своевременная доработка, контроль и отсылка данных накладных на удаленный склад, исправления накладных и т.д.)
Отдел 3: Бухгалтерия, касса.
Отдел 4: Контрольно-ревизионный отдел.

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


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо