Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.10.24;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]

2 Digitman © (03.10.02 12:11)
Да да, я чуть не туда посмотрел. Согласен я с тобой :)


 
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)
Просто у них неверно построены алгоритмы, отсутствует как класс такое понятие как резервирование товара, обработка недопустимыз ситуаций при расходе и т.д.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.10.24;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.63 MB
Время: 0.045 c
3-78305
Explorer
2002-10-04 07:35
2002.10.24
ДАнные за текущий год


1-78423
brestmarket
2002-10-15 16:20
2002.10.24
В WebBrowser использую относительные переходы по диску,


14-78627
blackweber
2002-10-02 23:28
2002.10.24
Всем.Всем.Всем... SMS (Save My Soul). Братья студенты и не только


7-78700
bob1906
2002-08-13 21:53
2002.10.24
Как объеденить два exe - файла в один, exe+exe=exe


1-78353
artgamer
2002-10-14 19:56
2002.10.24
Как создать несколько объектов одного типа в Runtime?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский