Подскажите, пожалуйста, как при работе в сети нескольких

← →
Larisa (2002-10-02 11:16) [0]

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

← →
Sergey13 (2002-10-02 11:31) [1]

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

← →
VictorT (2002-10-02 12:45) [2]

> Sergey13 © (02.10.02 11:31)

А линк дать можешь?

← →
Digitman (2002-10-02 12:45) [3]

В принципе это реализуемо. IB6 имеет некоторые средства для асинхронной нотификации заинтересованных онлайн-клиентов о событиях базы. Cм. ISQL-ключ.слово "POST_EVENT". Механизм этот очень ограничен из за невозможности сопровождать нотификации (в строковом виде, известным и серверу и клиенту) произвольным набором параметров, например, идент-ры записей, фактически добавленных неким клиентом в некую таблицу при подтвержденной транзакции.
Возможно, в будущем механизм параметрических событий и будет реализован в том или ином виде в FB/YA, но ждать и надеяться на это не стоит.
Здесь есть три выхода :

1. использовать данный механизм в сущ.виде, т.е. обновлять нужные НД на клиентской стороне полностью при получении от сервера нотификации, информирующей о фактах вставки/удаления/модификации записей (без указания - каких конкретно) в интересующих таблицах

2. дополнить (1) собственными средствами временной фиксации конкретных изменений, нетривиально используя все возможности мощного IB UDF-механизма

3. отказаться от затеи вообще

← →
Sergey13 (2002-10-03 09:17) [4]

2VictorT © (02.10.02 12:45)
>А линк дать можешь?
Линк на что?
1.На мое мнение? Адрес в анкете.
2.На такую же ветку? http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1033133967&n=1
Блин, заставил самого искать.

← →
Johnny Smith (2002-10-03 09:59) [5]

2Sergey13 © (03.10.02 09:17)
Блин, заставил самого искать.
Вот, что значит грамотная организация! :))))
Главное, чтоб не заставил самого написать :)))

← →
Prooksius (2002-10-03 10:03) [6]

Ну не согласен я с Digitman
Да, событийный механизм в IB ограничен, но все равно можно что-то сделать.
У меня работает. В сети.
Пробуйте, народ!

← →
Desdechado (2002-10-03 10:43) [7]

Лучше, имхо, пусть юзер сам по кнопке обновляет.
А то представьте ситуацию: 10 человек работают с БД, каждый вносит 2 изменения в минуту. Так у всех все время будет уходить не на работу, а на чтение изменений, которые ему, может, и не нужны (ну работает он с данными таблицы, но с другими!). Зачем все это?

← →
Prooksius (2002-10-03 10:52) [8]

2 Desdechado © (03.10.02 10:43)
Решений этого много.
Например, рефрешить через определенный интервал (не сразу по приходу сообщений) или когда соберется определенное их количество.
Рефрешить в моменты, когда юзер ничего не делает.
В конце концов так разделять работу клиентов, чтобы такого не происходило.
Да, конечно параметры в евентах нужны, как воздух...
Ну нет их и все тут.

← →
Anatoly Podgoretsky (2002-10-03 10:52) [9]

Добавить дергание отображения, можно избежать, тормоза на получения нового набора данных, а нафиг он нужен и прочее

← →
AlexSam (2002-10-03 11:05) [10]

Если кол-во редактируемых таблиц ограничено то механизм реализуется след. шагами
1. К редактируемым таблицам прицепляются триггереры на INSERT,UPDATE,DELETE со строкой "post_evant "update" ".
2. В приложение устанавливается компонент IBEvants.
3. В событии OnEvantAlert ставится процедура обновления набора данных.

И все!!! У меня прекрасно ЭТО работает.

← →
Prooksius (2002-10-03 11:07) [11]

2 AlexSam (03.10.02 11:05)
Это и ежу понятно. Ты попробуй поработай, если у тебя 30 юзеров одновременно меняют одну таблицу.

Посмотри что писал Desdechado © (03.10.02 10:43)

← →
AlexSam (2002-10-03 11:12) [12]

Наверное, все зависит от задачи...
Если оперативность вывода информации на экран не нужна, то вариант Desdechado, если необходима - мой...

← →
Digitman (2002-10-03 11:31) [13]

>Prooksius

> Ну не согласен я с Digitman

В чем не согласен-то ? Поясни, я не понял.

← →
Prooksius (2002-10-03 11:38) [14]

2 Digitman © (03.10.02 11:31)
Да с его словами "В принципе это реализуемо. " :)

← →
Prooksius (2002-10-03 11:40) [15]

Блин, что это я написал... %)

2 Digitman © (03.10.02 11:31)
Я просто хочу сказать, что все это реализуется, да сложно, но реализуется. И отказываться от этой затеи нельзя, IMHO.

← →
Digitman (2002-10-03 12:11) [16]

>Prooksius

Так ведь и я сказал, что это реализуемо !

← →
Prooksius (2002-10-03 13:12) [17]

← →
Sergey13 (2002-10-04 10:54) [18]

И все таки такой подход к Event-ам не правилен с теоретической точки зрения. ИМХО. Все задающие такие вопросы, как правило, боятся исключительных ситуаций, когда чего то не хватит для транзакции. Товар со склада уже ушел весь, а на него еще расход вешают - самый распространенный пример.
Тут есть два варианта:
1.Список товаров маленький, а число пользователей сопоставимо большой. 10 менеджеров продают 10 сортов мороженого например. В этом случае то что на складе не осталось какго-то конкретного сорта - это исключительная ситуация, но в широком смысле этого слова. Что это за компания, выпускающая 10 товаров и не обеспечивающая достаточное количество их на складе. Нонсенс.
2.Список товаров большой, число пользователей нет. 10 менеджеров продают 10000 видов канцтоваров. В этом случае вероятность того, что несколько человек ОДНОВРЕМЕННО работают с одним товаром настолько мала, что обрабатывать каждый их тык для всех остальных - просто глупо.

К обоим случаям - не всякое изменение данных критично для других пользователей. Какая разница менеджеру скольео в графе наличие - 10000 или 9825, если средняя партия отпуска 50~100 штук.

В общем - исключительные ситуации надо и обрабатывать как исключительные ситуации, а не перестраховываться постоянно. Накладно больно получается.

А Event-ы уместны для другого, ИМХО. Например сообщить кладовщику, что клиент оплатил товар и сейчас придет за товаром - готовь по этому списку.

Что то я расписался. Но наболело - я вот борюсь с таким Event-информатором на работе. Задолбал козел. Как его прога(склады как раз) начинает работать - тормоза по всей базе(хотя и оракл на дуал Р3). Гад - однозначно.

← →
Prooksius (2002-10-04 11:19) [19]

2 Sergey13 © (04.10.02 10:54)
Просвети, плииз, интересно, в Оракле события с параметрами, или, как в Interbase, только одна строчка?
Т.е. можно ли по событию определить, какая именно строчка в табл. была изменена?

← →
Sergey13 (2002-10-04 11:36) [20]

2Prooksius © (04.10.02 11:19)
Да в принципе можно. Длина мессаджа то ли 1500 то ли 1800 символов максимально - не помню точно. Чего ты туда напишешь - твое дело.

← →
Prooksius (2002-10-04 11:47) [21]

2 Sergey13 © (04.10.02 11:36)
Ну тогда ваш Event-информатор просто глупо перечитывает Dataset-ы, поэтому и тормоза.
Не злись на него, а попроси еще подумать :)

← →
Sergey13 (2002-10-04 11:59) [22]

А ты предлагаешь еще анализировать "А надо ли мне это?". Т.е. пробежаться по датасету и сказать "Неа, нафиг". Зачем вообще это делать? Именно так я ставлю вопрос.

← →
Anatoly Podgoretsky (2002-10-04 12:07) [23]

Sergey13 © (04.10.02 10:54)
Просто у них неверно построены алгоритмы, отсутствует как класс такое понятие как резервирование товара, обработка недопустимыз ситуаций при расходе и т.д.

Подскажите, пожалуйста, как при работе в сети нескольких Найти похожие ветки