Уважаемые мастера!
Есть сетевая база (FB2.5), несколько пользователей одновременно работают с таблицами.
Как "перехватить" событие по вставке в базу записи другим пользователем (если это реально)?

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

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


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

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

А есть радикальное решение - уйти от "табличной" идеологии к "документной"

каждый раз дергать по Eventу - все равно нужно делать FullRefresh(я так понял FIBPlus используются)... тогда разница? я давеча думал на эвентах реализовать реакцию на "чихи" по измененияю справочника(ов).. задвинул... сделать то раз плюнуть.. но пользы... мало.. вот если там предельное кол-во упало ниже минимального, то в отдел поставок приходит сообщение... а отдел продаж это не особо интересует(кроме момента продаж).. потому - лучше FullRefresh по необходимости.. однозначно.. а то если каждый раз сетку грузить.. не, в локалке куды не шло.. а вот при медленном коннекте....

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

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

Спасибо, счас попоробую оба варианта, но наверно на евентах остановлюсь - сеть локалка, юзеров не более 10-20 (на пике активности :)

> каждый раз дергать по 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-ов.

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

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

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

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

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


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

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

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

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

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

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

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

MsGuns ©   (02.06.09 22:18) [10]


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


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


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


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

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

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

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

> MsGuns ©   (01.06.09 20:55) [2]
> А есть радикальное решение - уйти от "табличной" идеологии
> к "документной"

это уже второй дан :)
сорри за оффтоп

MsGuns ©   (03.06.09 00:30) [12]


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


В доступных, очевидно.


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


И че ? Ну слинял. Не подтвердил в указанный регламентом интервал - места снова достпупны.


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


Хотя бы по той простой причине, что с системами бронирования (авиаперевозок) я общаюсь больше 15 лет.

> MsGuns ©   (03.06.09 00:30) [12]
>
> Хотя спорить с тобою уволь ;)
>

При чтении ветки хотел похохмить на эту тему с тобой, но опоздал :(
ИШ своим [14] испортил всю малину! :)
На эту тему можно ещё поговорить с vuk'ом. (Если он захочет).

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

> Игорь Шевченко ©   (03.06.09 01:55) [16]
>
> Кстати, о бронировании и просмотре изменений, внесенных
> другими пользователями - при продаже билетов на сеанс в
> кино такого рода изменения вполне уместно организовывать
> через оповещение. Перед кассиром план зрительного зала,
> закупленные места помечаются одним цветом, свободные другим,
>  в соседней касе продали на 13-е место 13-го ряда - сразу
> всем видно, что на этот конкретный стул хрен кого еще усадишь.
>

Кстати и я о том же. :) Но не о билетах.

>Игорь Шевченко ©   (03.06.09 01:55) [16]

О как !
А зачем тогда был [14] - типа крутость показать ?
Я как бы и сам о таком догадывался ибо тоже не вчера в горшок стал попадать, а вот автору мозги, ИМХО, запудривать не стоило б. Тем более там у него и так не густо пока ;)

MsGuns ©   (03.06.09 09:05) [18]

Я ценю твою заботу об авторе.


> А зачем тогда был [14]


Исключительно для тебя, в пояснение поста [10].