Уважаемые мастера!
Есть сетевая база (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].

Интересно было коменты почитать после вынужденного перерыва.

> автору мозги, ИМХО, запудривать не стоило б. Тем более там
> у него и так не густо пока ;)


ничё, интересно было поразмыслить. В плане не густо согласен, я пока собаки ни одной не съел :)

Кстати о том что же нужно автору:
это ближе к кассе с билетами чем к брони билетов, а именно: группа {студентов} из 10-15 чел. вбивает в базу некоторые данные о себе. При этом некоторые lookup-поля используют таблицы подстановки. Например Иванов выбирает предмет "Математика" и ставит себе оценку. Если математики нет, жмёт доп. кнопку и в отдельном мастере добавляет нужный предмет.
Так вот, если в этот момент Петров добавит тот же предмет, то или их в справочнике будет 2, или счаботает исключение в случае уникального ключа у того из них, кто вторым сделает пост.
В данном случае считаю обоснованным применение оповещений, но в данный момент ломаю голову над вот чем:
в тригеры поставил рассылку сообщений, но если юзер А делает к примеру Insert, ему тоже приёдет сообщение, как и всем остальным - а это уже не нужно. Параметр в сообщение не передашь.
Пока вижу выход один:
убрать рассылку из тригеров, оформить хранимой процедурой и вызывать из слиентского приложения её, при этом на время отсылки не обрабатывать получение соответствующего сообщения.
Знаю что метод кривой, кто знает как можно более прямо сделать?

> Так вот, если в этот момент Петров добавит тот же предмет,
>  то или их в справочнике будет 2, или счаботает исключение
> в случае уникального ключа у того из них, кто вторым сделает
> пост.


> кто знает как можно более прямо сделать?

Обработать в программе возникшее исключение.

> Обработать в программе возникшее исключение.


это понятно.
но хотелось чтобы у Петрова в списке появился предмет, добавленный Ивановым (плюс ещё можно Balloon в трэй-иконке показать, чтобы привлечь внимание)!
Но сообщения ловят все подписанные клиенты, в т.ч. и Иванов, который его инициировал. Ему нет необходимости его обрабатывать - его датасеты уже содержат все изменения!

> Например Иванов выбирает предмет "Математика" и ставит себе
> оценку. Если математики нет, жмёт доп. кнопку и в отдельном
> мастере добавляет нужный предмет.


А если у Иванова двойка по родному языку и он выбирает "Матиматека", а у Петрова тройка и он выбирает "Мотематика" ?

> [20] TheEd   (03.06.09 14:07)
> группа {студентов} из 10-15 чел. вбивает в базу некоторые данные о себе.

Это нечто рельно нужное или очередная лаба?
В реальности нет ничего страшнее чем справочники, заполняемые кем попало по желанию правой ноги.

Если математики нет, жмёт доп. кнопку

... и в вузе сразу же начинают преподавать математику.
физрука снимают с пары и посылают преподавать дифференциальное исчисление.

> Это нечто рельно нужное или очередная лаба?


лабы, слава Богу, давно в прошлом :)
хотя... Лабы сдают преподам, а работу - начальству. Разницы большой нет, только степень ответственности + некоторое скудное материальное вознаграждение, называемое зарплата :)

> [26] TheEd   (03.06.09 16:00)
> только степень ответственности + некоторое скудное материальное
> вознаграждение, называемое зарплата :)

Значит ты безответственный и зарплату тебе не повысят. 8-)

ну если зарплата, то логичен вопрос, почему программа уже у набивальщиков данных, а в базе еще нет математики?

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

2 Sergey13 [27]:
её в бюджете платят не по заслугам а так, чтобы человек не сбежал :(

Тем не менее принципиально - студент может сам добавить пункт справочника.

Это у кого такие интересные принципы?
А если студень туда забьет предмет "хиромантия" ?
Ты начшень здесь парить всем моск как перехватить "хиромантию"?

> [29] TheEd   (03.06.09 16:36)
> Тем не менее принципиально - студент может сам добавить пункт справочника.

Ну значит готовься к наличию оценок по "Хрен знает чему" и "Какой то фигне". 8-)

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

плюз на зряплате вуз сэкономит.

>Игорь Шевченко ©   (03.06.09 11:00) [19]
>> А зачем тогда был [14]
>Исключительно для тебя, в пояснение поста [10].

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

Я также не комментирую утвержение о бронировании того не знаю чего - вы там в авиации, очевидно, знаете.

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

> MsGuns ©   (04.06.09 00:09) [33]
>
> Но вот к чему эти сентенции автору, которому, очевидно,
> надо просто сделать "как в парадоксе" (наверное препод так
> сказал)

А как сделано это в парадоксе?

При открытии справочника оптимально получать его свежее состояние.
От дублей в справочнике, который заполняют юзеры, не спасет ничего.
Какую то часть можно отсеять по уникальному индексу на название без учета регистра.

> А если студень туда забьет предмет "хиромантия" ?


> Ну значит готовься к наличию оценок по "Хрен знает чему"
> и "Какой то фигне". 8-)

в принципе - всё правильно, но
в контексте моей задачи это не возбраняется. Студни пишут сами о себе, это не претендует на реальность (для этого зачётки есть). Кроме этого есть ещё много чего, что они о себе пишут, ложат фоты и т.д.. А вот потом это всё в отчёт формируется, это студень сам о себе писал за время учёбы (дневник достижений что-ли?). Может им к выпуску самим интересно будет глянут что там наваяли.
Практика уже сейчас показывает что подход работает - 70-90% пишут добросовестно и им самим интересно. Остальные не только херомантию в справочник тиснуть смогу, но и Череззаборногузадерищенко - в фамилию :) Для этого предусмотрена процедура типа модерации.

В принципе хорошо пообщались, тему можно свернуть, хотя пока нет полной ясности как ловить только чужие сообщения (или передать в сообщение параметр).

да
такие бредовые ветки чем раньше свернешь - тем полезней окружающим

>В принципе хорошо пообщались, тему можно свернуть, хотя пока нет полной ясности как ловить только чужие сообщения (или передать в сообщение параметр).

Да уж, "пообщались". Автор как пребывал в потемках, так и пребывает дальше

> Да уж, "пообщались". Автор как пребывал в потемках, так
> и пребывает дальше


Уважаемый MsGuns! Если я не прав, прошу меня поправить, но:
единственные параметры сообщения FB - это его имя и количество произошедших событий. Тут не разгуляешься...
И сообщения отправляются всем подписанным клиентам, поэтому идентифицировать своё собственное можно только поплясав с бубном :)

Во всех проектах, функции заполнения всего всеми были прикрыты.
Вводились обязанности админа или оператора БД, который набивал важные данные.
Даже редактирование менеджерами инфомации о своих клиентах блокировалось и перекладывалось на ОБД.
Иначе возникал бардак.
В любую бухгалтерию загляни, даже один человек в состоянии десять раз повторно вбить один и тот же наименование в справочник с вариациями:
* Пуговица круглая
* "пуговица круглая"
* Круглые пуговицы
* Пугавицы круглоя
и прочие пугвицы и крглыя...
ПАтаму, что не нашлась в нужный момент "Пуговица" при поиске по "пгвица".
А то и вообще не искалось при добавлении... Они ж все и так помнЮт... Что не было еще такой позиции.

Нат ©   (07.06.09 23:20) [40]

Вот смех-смехом, а в MS Money, например, оно предлагает выбрать из имеющихся, но если набрал то, что не совпадает с предложенным, запишется новое.
Рассчитано на то, что человек сам себе вредить и сам себя путать не будет :)

А когда используется рабский труд, тогда нужны жесткие ограничения в виде foreign keys :)

> TheEd   (03.06.09 16:36) [29]
>Тем не менее принципиально - студент может сам добавить пункт справочника

Бред, однозначно. Справочник этот есть расписание предметов. Заполнятся должен исключительно по какедрам. Иначе первое что появится так это куча странных предметов вида "раскладывание косынки"


> TheEd   (06.06.09 18:19) [39]

А что будет если 2 юзера одновременно добавят предмет "БлаБлаБЛа" единовременная нагрузка 10-15 человек, уже вполне реально.
ИМХО в таком случае надо просто позволить не только выбрать но и набрать руками. На добавление повесить проверку - если есть айдишник уже то подставить если нет то добавить новый предмет.
То есть Вася не нашел предмета и вводит его руками.
Ввел "Алгебра" - процедура нашла оную и подставила ID
Ввел "херомантия" - процедура не нашла оную, проведена доп. проверка по какому-нибудь SoundEx нашла там предмет " Хиромантия" и подставила его ID.
Вася вводит - "... <цензура>..." процедура проверки налетела на стопслово и вернула сообщение об ошибке в котором попросила Васю отнестись сурьезно к данному вопросу.

> [42] Павел Калугин ©   (09.06.09 15:40)
> процедура проверки налетела на стопслово

База стоповых слов будет стопудово больше "боевой". 8-)

> Ввел "херомантия" - процедура не нашла оную, проведена доп.
>  проверка по какому-нибудь SoundEx нашла там предмет " Хиромантия"
> и подставила его ID.
> Вася вводит - "... <цензура>..." процедура проверки налетела
> на стопслово и вернула сообщение об ошибке в котором попросила
> Васю отнестись сурьезно к данному вопросу.

Дохляк. Реализация подобных проверок будет сложнее самой системы.

У разработчика одно задумывание проверок займет неделю.
Альтернатива:
Секретарша декана набивает в табличку 20-30 названий.
За 20 мин, включая перекур и перекоф.
Все. Вопрос закрыт.

> [44] ANB   (09.06.09 18:06)
> Дохляк. Реализация подобных проверок будет сложнее самой
> системы.

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

>  или отказыватся от ввода предметов студентами.

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

ANB   (10.06.09 11:34) [47]

Приковывать не пробовали ?

> Приковывать не пробовали ?

КЗОТ запрещает :(

в серьезных организациях есть целый отдел MDM - Master Data Management
и процедуры прописаны что нужно сделать чтобы добавить материал или поставщика, целое флоу с инициаторами, подтверждающими, координаторами и наконец непосредтсвенно заносящими в систему людьми

>Polevi ©   (10.06.09 17:07) [50]
>в серьезных организациях есть целый отдел MDM - Master Data Management

Ну это в О-о-о-чень серезных организациях. Где деньги считают мешками.
Чтонить вроде обладминистраций или рослюминьгазнефтьнесчет.
Ну или Сп с америкосами какими-нибудь, у которых антирес не в том, чем солсна контора занимается, а чтоб бабло отмывать

В менее серьезных организациях достаточно секретаря напрячь устным распоряжением