Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Отображение изменений, внесённых в БД другими пользователями [D7, FB2.5]

Страницы: < 1 2 3
TheEd © (2009-06-01 17:19:00)
Уважаемые мастера!
Есть сетевая база (FB2.5), несколько пользователей одновременно работают с таблицами.
Как "перехватить" событие по вставке в базу записи другим пользователем (если это реально)?

зы:
Насколько я понимаю, сервер БД не оповещает клиентов о подобных событиях, т.е. выхода два:
- или время от времени делать FullRefresh
- или трехзвенку строить
Есть более "прямые" решения?

MsGuns (2009-06-03 00:30:00) [41]
>Игорь Шевченко © (02.06.09 22:36) [11]
>Не! Оно сразу говорит - зарезервируй, без предварительных запросов.

Ну да ? И где ж оно будет резервировать, в каких поездах и вагонах ?
И какого оно будет резервировать, ежели покупатель заказал полста билетов и слинял "как будто в туалет" ?

Хотя спорить с тобою уволь ;)

Игорь Шевченко (2009-06-02 22:36:00) [42]
MsGuns © (02.06.09 22:18) [10]

> Угу. При запросе свободных мест местов было. А вот при попытке
> зарезервировать - индейская хижина. В этом и фишка.

Не! Оно сразу говорит - зарезервируй, без предварительных запросов.

> А таким, что если сервер будет уведомлять стотощ клиентов

И че ? Хоть стопицоттыщ - уведомление не есть сколько-нибудь ресурсоемкий процесс, если сервер умеет одновременно поддерживать стопицоттыщ подключений, то послать лишний пакет им - не так уж страшно замедлит его работу, что он не сможет чем-либо заниматься.
Впрочем, это легко проверяется на практике - в Demos\DelphiWin32\VCLWin32\Db\IBX\IBXEvents есть как раз проект для этих самых уведомлений, компилируешь, запускаешь много экземпляров...

MsGuns (2009-06-02 22:18:00) [43]
>Игорь Шевченко © (02.06.09 16:56) [9]
>Система резервирования работает очень просто - желающий отправляет >запрос на сервер и говорит - хочу зарезервировать пол-самолета (пол->гостиницы) на такое-то число.
>Ей в ответ - зарезервировано или фиг вам, местов нету.

Угу. При запросе свободных мест местов было. А вот при попытке зарезервировать - индейская хижина. В этом и фишка.

>Каким боком понимание такого факта поможет автору вопроса ?

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

Игорь Шевченко (2009-06-02 16:56:00) [44]

> Блин, в 667-й раз рекомендую присмотреться как работает
> система резервирования и продажи билетов - многое станет
> ясным

Система резервирования работает очень просто - желающий отправляет запрос на сервер и говорит - хочу зарезервировать пол-самолета (пол-гостиницы) на такое-то число.

Ей в ответ - зарезервировано или фиг вам, местов нету.

Каким боком понимание такого факта поможет автору вопроса ?

MsGuns (2009-06-02 16:12:00) [45]
Какой нафих таймер !!!! Какой эвент !!!!!!!!!!!!!!
Блин, в 667-й раз рекомендую присмотреться как работает система резервирования и продажи билетов - многое станет ясным

Это все придумал Черчиль (Парадокс) в 18-м (80-х) году ;)

Sergey13 (2009-06-02 10:25:00) [46]
> [5] TheEd (02.06.09 08:39)
> юзеров не более 10-20 (на пике активности :)

И все продают единственный (последний) чайник со склада? 8-)

PEAKTOP (2009-06-02 09:42:00) [47]
> каждый раз дергать по Eventу - все равно нужно делать FullRefresh(я
> так понял FIBPlus используются)...

Зачем ? Можно и по таймеру: у FIBPlus у транзакции есть свойство Timeout и TimeoutAction. Timeout - это внутренний таймер, TimeoutAction - действие.

Если транзакция, читающая данные, будет
isc_tpb_read_committed
isc_tpb_no_rec_version
isc_tpb_read
isc_tpb_nowait или isc_tpb_wait - неважно, зависит от задачи

а транзакция, в которой идет запись
isc_tpc_consistency
isc_tpb_write

То имеем "живой" набор данных. И безо всяких Event-ов.

TheEd (2009-06-02 08:39:00) [48]
Спасибо, счас попоробую оба варианта, но наверно на евентах остановлюсь - сеть локалка, юзеров не более 10-20 (на пике активности :)

Германн (2009-06-02 00:46:00) [49]

> Виталий Панасенко(дом) (01.06.09 22:08) [3]
>
> каждый раз дергать по Eventу

Иногда это нужно, но только очень иногда.

Виталий Панасенко(дом) (2009-06-01 22:08:00) [50]
каждый раз дергать по Eventу - все равно нужно делать FullRefresh(я так понял FIBPlus используются)... тогда разница? я давеча думал на эвентах реализовать реакцию на "чихи" по измененияю справочника(ов).. задвинул... сделать то раз плюнуть.. но пользы... мало.. вот если там предельное кол-во упало ниже минимального, то в отдел поставок приходит сообщение... а отдел продаж это не особо интересует(кроме момента продаж).. потому - лучше FullRefresh по необходимости.. однозначно.. а то если каждый раз сетку грузить.. не, в локалке куды не шло.. а вот при медленном коннекте....

MsGuns (2009-06-01 20:55:00) [51]
А есть радикальное решение - уйти от "табличной" идеологии к "документной"

Игорь Шевченко (2009-06-01 17:24:00) [52]

> Насколько я понимаю, сервер БД не оповещает клиентов о подобных
> событиях, т.е. выхода два:

оповещает через Event Alerter

Более прямое решение - делать Full Refresh, то есть, пользователь сам выбирает, когда ему смотреть, кто что поменял

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

Наверх

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