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

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

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

Альтернатива post_event. [IB6.x]

int64 © (2002-05-24 08:41:00)
Помогите реализовать хороший аналог post_event/TEventAlerter.

Хороший в смысле:
1. Не глючит.
2. Не требует обязательной регистрации событий в клиенте. Т.е. может принимать абсолютно все сообщения.
3. И самое главное помимо сообщений может сразу принимать данные.

Мыслю так. На стороне сервера всё реализуется в виде UDF. Она принимает входные параметры и отсылает их посредством TServerSocket клиентам. На клиенте соответственно TClientSocket.

Теперь исходя из этого вопрос. Можно ли зашить такую (или какую подобную) передачу данных в коннекты, сессии,... короче, внутренности IB. Чтобы все манипуляции в дезайнтайм свелись к вызову в триггерах/SP UDF, а на клиенте помещением на форму компонента.

int64 (2002-05-25 22:03:00) [1]
Конечно же ещё вариант, просматриваемый у younghacker и Alexandr.

3. Ввести служебные таблици для каждой таблицы (журналы изменений). Толстый клиент (по таймеру или событиям) просматривает журналы на предмет новых записей и удаляет старые.

Тогда не будут теряться апдейты, но система, и без того не реалтайм, потеряет много в своей оперативности.

Такой вариант подойдёт для не "интенсивных" систем. Проводок документов, например. В моей же области журналы быдут только пухнуть.

К тому же хотелось бы "вести моноторинг" на всех клиентах.

int64 (2002-05-25 21:12:00) [2]
2 Pavel_S © (25.05.02 16:17)

> записывай все изменения куда нибудь

Ну надо же. А я чего пытаюсь добиться у аудитории?

Подвожу резюме выше сказанного.

1. Инициировать запросы с клиента ("не изменилась ли какая запись?"). По таймеру или евенту.
Клиент может тормозить и пропускать обновления.

2. Извратить UDF, добавив в неё сокет на левую программу. Распихать UDF"ы по триггерам.
UDF будет отсылать не подтверждённые данные.

Есть ещё варианты? Не стесняйтесь предлагайте.

Pavel_S (2002-05-25 16:17:00) [3]
А ты через тригеры сделай и записывай все изменения куда нибудь, как например в IBExpert сделан лог

int64 (2002-05-25 08:07:00) [4]
kaif © (24.05.02 14:13)

Я не могу позволить себе терять обновления в записях. Сами старые записи не нужны. В БД нужно хранить только последние. Так же надо иметь историю всех записей со всех таблиц в виде некоторого представления (напимер суммы). Реализовать такую "сумму" в БД нельзя. Поэтому нужно перехватывать малейшие изменения.
Я уже могу получить устаревшие данные когда опрашиваю БД по post_event. А тем более по таймеру.

kaif (2002-05-24 14:13:00) [5]
Почему бы просто циклически (раз в 5 секунд) с клиента не опрашивать эти 20 таблиц, если там так мало записей? Попробуй, может это заработает быстро. А если не заработает быстро, значит у тебя сеть 10 mbit и ее надо менять на 100 mbit. Иногда лучше не мудрить с программированием, а улучшить железо.
Если, конечно, речь идет просто о мониторинге...

int64 (2002-05-24 13:42:00) [6]
Да. Именно база. Эти 20 таблиц только часть её. И данные поступают только с клиентов. Ещё внутри немного перевариваются, чтобы распихаться по таблицам.

Хочу снимать показания базы через UDF.

Alexandr (2002-05-24 13:30:00) [7]
ты уверен, что для этого тебе база данных нужна?

int64 (2002-05-24 13:28:00) [8]
Имеется около 20 таблиц. В каждой около 100 записей. Записи быстро модифицируются; новые не добавляются. Нужен какой-угодно, но оперативный мониторинг.
Как его ещё сделать?

Alexandr (2002-05-24 13:19:00) [9]
че это за "данные из UDF" и где они "ничего не делают", и как это они "выходят наружу" и где это они "ждут commit"
Подумай на трезвую голову об ответах на эти вопросы

int64 (2002-05-24 13:16:00) [10]
Данные из UDF ничего не делают, а выходят из базы наружу. И там ждут commit. Так можно?

Только как этот commit поймать? И боюсь они десяь раз обновятся до подтверждения.

Alexandr (2002-05-24 13:05:00) [11]
никак.
UDF вне контекста транзакции так же как генераторы и внешние таблицы.

P.S. как ты себе представляешь откат работы UDF?

int64 (2002-05-24 12:37:00) [12]
С событиями всё понятно, я уже забыл за них.
Интересуюсь:
Как UDF под commit запустить. Не в конкретном случае, а впринципе в каком-нибудь варианте возможно?

Alexandr (2002-05-24 12:10:00) [13]
через задницу можно, но не UDF.
1) Сделать служебную таблицу, в которую события писать.
2) Отдельное приложение/сервис периодически лезет в эту таблицу, читает новые события и рассылает их своим способом клиентам

int64 (2002-05-24 12:00:00) [14]
Огромное спасибо.
Я то и спрашивал, чтобы не изобретать велосипедов.

Вот ещё что, черт с ними с алертерами, тут просто ситуация: если UDF без commit"а идут, можно как-нить их под commit запустить. Хоть через з....цу.

И, пожалуйста, уточните на счёт:
> только udf будут срабатывать сразу, а не после commit, как
> events

тут разночтение по поводу events.

younghacker (2002-05-24 10:43:00) [15]
Да используй SuperIbEventAlerter. Кто тебе мешает зарегистрировать все события сразу? Под IBX, FIB+ глюков не замечено. Под BDE есть неприятный глюк вызывающий довольно длительное зависание приложения при отсоединения клиента от базы. Но как я разобрался глюк связан с проблемами самого BDE. Вызов уходит в BDE и зависает там. А так работает замечательно.

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

А по поводу UDF Александр прав. Для своего метода видимо подойдет такой способ. Создаешь таблицу которая содержит например идентификаторы всех событий и количество возникновений событий. Клиентское приложение регулярно - например раз в пять сек. считывает эту таблицу. смотрит какие поля изменились и формирует внутреннее событие. Ну а тригера и процедуры базы инкрементируют определенные записи таблицы событий. Вот и все завязано под commit.

Удачи!

Alexandr (2002-05-24 10:20:00) [16]
ага, только udf будут срабатывать сразу, а не после commit, как events

Наверх

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