Синхронизация данных

← →
Volodya_ (2004-04-28 10:03) [0]

Есть клиент-серверное приложение с которым работает много пользователей, которые вносят изменения. Как сделать чтобы при изменении одним пользователем измененения сразу было видно и другим пользователям? Используемые компоненты: AdoQuery, DBGrid

← →
Reindeer Moss Eater © (2004-04-28 10:05) [1]

А они что ли не видны?
Уровень изоляции транзакций смени с репитабл рид на любой другой

← →
Johnmen © (2004-04-28 10:05) [2]

А зачем СРАЗУ и ВСЕМ ?

← →
Sergey13 © (2004-04-28 10:11) [3]

2Volodya_ (28.04.04 10:03)
>измененения сразу было видно
Расшифруй слово "сразу". Т.е. даже если "другой" юзер в отпуске, ему на мобилу шли СМС-ки из базы?

← →
Reindeer Moss Eater © (2004-04-28 10:12) [4]

Лучше пусть расшифрует слово "видны"

← →
Ega23 © (2004-04-28 10:21) [5]

Рефреш запроса по таймеру на клиенте делай. Или пингуй сервер на предмет изменений.

← →
Sergey13 © (2004-04-28 10:29) [6]

2Ega23 © (28.04.04 10:21) [5]
Но правильнее, ИМХО - одна большая кнопка с надписью "Обновить набор данных". 8-)
Не могу понять я таких требований в программе (а такие вопросы часто попадаются). В результате то что? Что бы как в кине про Матрицу - сидит чел, а на экране постоянно бегут/изменяются колонки цифр? А он сидит, смотрит на них и думу думает.

← →
Ega23 © (2004-04-28 10:37) [7]

Но правильнее, ИМХО - одна большая кнопка с надписью "Обновить набор данных". 8-)

Совершенно верно. У меня везде так и сделано. Но товарищ хотел "автоматическое" обновление. :о)

← →
Volodya_ (2004-04-28 10:39) [8]

Ну что не понятно? Привожу прстой пример:
Есть база на сервере, есть авиабилетные кассы
Вот в одной кассе продали билет на такой то рейс, на такое то место, вот нужно чтобы во всех остальных кассах было видно что этот билет уже продан! Что им каждую секунду жать кнопочку рефреш??? а если база огромная ?? и запрос выполняется не доли секунд

← →
Andrey V. © (2004-04-28 10:39) [9]

Как правило такое желание (видеть срзу изменения) происходит при переходе с файл-серверов. И бывает трудно обяснить заказчику , что это ему не нужно.

← →
Andrey V. © (2004-04-28 10:42) [10]

2Volodya_
Ну так представь как он будет автоматом тебе рефрешить , когда у тебя запрос "выполняется не доли секунд". Ты можешь просто не смочь начать работать - Будешь смотреть как у тебя экпан рефрешится.

← →
Reindeer Moss Eater © (2004-04-28 10:46) [11]

Volodya_ (28.04.04 10:39) [8]

вот нужно чтобы во всех остальных кассах было видно что этот билет уже продан! Что им каждую секунду жать кнопочку рефреш??? а если база огромная ?? и запрос выполняется не доли секунд

Глупость. Полнейшая.
Допустим выполнился рефреш и кассир видит, что есть свободное место.
Жмет кнопку "продать билет". А на другом рабочем месте в промежуток между этой проверкой и нажатием кнопки билет этот уже был продан.

Нужен был этот рефрешь? Нафик не нужен.

← →
Ega23 © (2004-04-28 10:46) [12]

Volodya_ (28.04.04 10:39) [8]

Объясняю.
Когда человек подходит к кассе, продавец спрашивает его, какой рейс ему нужен. В какой город. И т.п. В этот момент идёт обновление выборки. Далее кассир начинает оформлять билет на какое-то место какого-то рейса. В этот момент на сервере должна сработать блокировка данной записи, дабы никто другой не смог его оформить. Закончив оформлять, продавец регистрирует в базе факт продажи. В этот момент запись о данном билете исчезает из списка свободных.

А запрос выполняется не доли секунд - как правило пользователю не нужно более 100 записей в выборке. Должна быть хрошая система фильтрации.

← →
Volodya_ (2004-04-28 10:51) [13]

Ну что нету никакой возможности обновить только те записи котрые поменялись не делая рефреш?

← →
Ega23 © (2004-04-28 10:54) [14]

Вот представь: у тебя 1000 касс. В каждой ксаае каждые 10 минут продаётся по билету. Каков будет сетевой траффик и нагрузка на сервер БД? Это первое.
Второе. предположим, оформление билета занимает 1 минуту. В кассе №1 начали оформлять. Через 30 секунд в кассе №763 тоже начали его оформлять (т.к. он ещё не продан). Что тогда?

← →
Sergey13 © (2004-04-28 10:55) [15]

А можно и не блокируя ничего. Поставить количество свободных мест на рейс и условие на него >=0 (ну или на каждое место признак занятости поставить если надо). При попытке продать лишнее оператор получает сообщение, что транзакция не прошла. После чего уже детально разбирается с конкретным случаем, с запросом последней инфы.
Так, ИМХО, самое правильное.

← →
Reindeer Moss Eater © (2004-04-28 11:00) [16]

Ну что нету никакой возможности обновить только те записи котрые поменялись не делая рефреш?

А что, нету возможности поверить в то, что это не нужно для решения твоей задачи?

← →
Ega23 © (2004-04-28 11:00) [17]

Sergey13 © (28.04.04 10:55) [15]
Тут однозначно сказать нельзя. См. пример [14]ю Хотя, с другой стороны, если чуваку в первой кассе начали оформлять билет, всё такое, а денег у него не хватило, он в "ROLLBACK" :о) пошёл, а в 763-й кассе транзакция в таком случае пройдёт.
ИМХО, надо подробно изложить на бумаге все случаи и идти к начальству. Пусть сами принимают решение. Но автоматическое обновление - это смертельно будет. Хотя если 2-3 клиента и запрос не "тяжёлый", то может это и решение.

← →
Volodya_ (2004-04-28 11:02) [18]

Хорошо такой пример:
Со своей проги я запускаю скрипт который делает изменения в базе, этот скрипт может запускаться очень часто ... после каждого выполенния скрипта мне нужно видеть эти изменения. Думаю что рефреш мне полностьью не подходить, он может не успевать делаться.

Кто что может сказать ещё по resync?

← →
Reindeer Moss Eater © (2004-04-28 11:02) [19]

Автоматическое обновление - это на самом деле принятие решения о допустимости продажи билета на клиенте, а не на сервере.

А это - неправильно.

← →
Курдль © (2004-04-28 11:02) [20]

О чем базар? Сдается мне, что все больше об ошибках в проектировании БД. Если грамотно расписать модель и реализовать продажу на процедурах (чтобы не вносить задержку из-за трафика сети), то никаких проблем не будет. Ведь все из вас работали с генераторами (последовательностями) и наверняка никогда их уникальный номер не повторился!

← →
Ega23 © (2004-04-28 11:06) [21]

Volodya_ (28.04.04 11:02) [18]

А что такое по-твоему частое запускание скрипта и получения резалтсета? Не рефреш?

← →
Volodya_ (2004-04-28 11:13) [22]

Ega23 © (28.04.04 11:06) [21]

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

← →
Ega23 © (2004-04-28 11:15) [23]

Volodya_ (28.04.04 11:13) [22]

Ничего не понял.
Есть один набор данных, а пользователь время от времени получает изменения к этому набору, так что-ли?

← →
Sergey13 © (2004-04-28 11:18) [24]

Volodya_ (28.04.04 11:13) [22]
А через датасет менять данные не пробовал?

← →
Плохиш (2004-04-28 11:18) [25]

> Volodya_ (28.04.04 11:13) [22]
> Пользователь жмёт кнопочку врямя от времени на определённых
> записях и выполняется скрипт который именяет данные, в гриде
> ж эти изменения не видны, нужно както обновить

А начиналось всё так красиво про авиакассы :-)

Так обнови свои данные после выполнения скрипта!

← →
P_Aleks © (2004-04-28 11:18) [26]

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

>Пользователь жмёт кнопочку врямя от времени на определённых >записях и выполняется скрипт который именяет данные, в гриде ж >эти изменения не видны, нужно както обновить

Ну вот для этого пользователяи рефреш данные после выполнения скрипта.

← →
Volodya_ (2004-04-28 11:23) [28]

Тогда см. [12]. Лично я сделал бы так.

← →
Volodya_ (2004-04-28 11:30) [30]

Ну допустим я знаю что изменилось, как обновить только те записи которые поменялись?

Изменить резалтсет.
Не пользуйся большими тяжёлыми выборками, у тебя фактически должны приходить данные по КОНКРЕТНОМУ рейсу на КОНКРЕТНУЮ дату. Это не так много записей. А волочить ВСЕ возможные, а потом вносить в эту выборку единичные изменения - мартышкин труд и глупость полная.

2Volodya_
А велик ли нужный датасет?

В этих данных:
Есть id записи, какой-то тип записи - название таблицы, или
тип отчета (здесь надо определится самому - по какому критерию
устанавливать какой отчет должен будет обновиться),
Дата обновления

В клиенте например по таймеру делать выборку из этой таблицы.
(выбрать все записи позже опр времени) А потом по типу
обновлять конкретную запись.

Ясное дело, что отчет должен хранить в себе id - записи.

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

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

а еще дополнительно для достоверности на таймер можно постатвить, но только так, чтоб не очень часто...

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

а вот в IB есть штука как POST_EVENT...

интересно наверно и в MSSQL есть что-нибудь такое...

Вы все сегодня обкурились с утра :(

Синхронизация данных Найти похожие ветки