Отслеживание изменения таблицы

← →
romeo © (2004-04-07 21:26) [0]

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

← →
romeo © (2004-04-07 21:26) [0]

← →
Алхимик © (2004-04-07 21:32) [1]

Никак.

← →
Алхимик © (2004-04-07 21:32) [1]

Никак.

← →
romeo © (2004-04-07 21:44) [2]

Других мнений нет? Просто какой тогда толк было создавать СУБД, в которой каждый пользователь будет в текущем сеансе приложения видеть только свои изменения?

← →
romeo © (2004-04-07 21:44) [2]

← →
Anatoly Podgoretsky © (2004-04-07 23:22) [3]

Хочешь устроить ад для пользователей?

← →
Anatoly Podgoretsky © (2004-04-07 23:22) [3]

Хочешь устроить ад для пользователей?

← →
Алхимик © (2004-04-07 23:23) [4]

Можно делать у пользователей регулярный рефреш таблиц. Но это извращение, на мой взгляд.
Различие между "Файл - сервер" и "клиент - сервер" знаете?

← →
Алхимик © (2004-04-07 23:23) [4]

← →
Anatoly Podgoretsky © (2004-04-07 23:27) [5]

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

← →
Anatoly Podgoretsky © (2004-04-07 23:27) [5]

← →
Ломброзо © (2004-04-07 23:57) [6]

romeo © (07.04.04 21:44) [2]

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

← →
Ломброзо © (2004-04-07 23:57) [6]

← →
romeo © (2004-04-08 08:54) [7]

Ладно, убедили.
Всем спасибо.

← →
romeo © (2004-04-08 08:54) [7]

Ладно, убедили.
Всем спасибо.

← →
Locker (2004-04-08 10:20) [8]

2 romeo

Рано сдался.

У нас в офисе на 5 пользователей система. Данные грузятся (в наследники TClientataSet) около минуты в начале сеанса работы, а потом только синхронизируются при помощи таблицы синхронизации. Загрузка сети (100 Мбит) в момент синхронизации - менее 2%. Интервал обновления - 5 сек. Обновление идет в основном потоке. Все остальное время, кроме, непосредственно, чтения и записи отдельных документов (этот процесс идет напрямую между БД и программой), сеть вовсе не загружена. БД - 25 таблиц; в некоторых - по 50 тыс. записей и более.
Короче, такой себе "очень толстый клиент" с трехзвенной внутренней архитектурой:
- служба данных, отвечающая за выборку, чтение, запись и синхронизацию данных;
- службы бизнеса, отвечающие за выполнение логики приложения; они, правда, немного смешаны со службой данных, так как хранят в себе загруженные таблицы (у TClientDataSet есть такой хороший метод: CloneCursor);
- службы представления явно не представлены (каламбур :) - хотя, под это понятие можно подвести отдельные документы и списки, клонированные от TClientDataSet из службы бизнеса; использование клонирования курсоров позволяет пользователю открыть одновременно любое количество представлений (например, журналы документов на разные интервалы дат) - при этом память на данные не тратится...
Правда, пожирает эта система до 50 МБайт ОЗУ. Но на офисном компьютере с Celeron 2,0 с 256 МБайт ОЗУ это совершенно незаметно.
Работает уже около года. Все рады и довольны...

P.S. Правда, не Paradox, а ADO + MSJet + *.mdb, но это та же хрень...

2 Anatoly Podgoretsky
>Хочешь устроить ад для пользователей?
Что конкретно Вы имеете в виду?

← →
Locker (2004-04-08 10:20) [8]

← →
Геннадий © (2004-04-08 10:47) [9]

>>2 Anatoly Podgoretsky
>>Хочешь устроить ад для пользователей?

>Что конкретно Вы имеете в виду?

И мне интересно, что имелось в виду?

← →
Геннадий © (2004-04-08 10:47) [9]

← →
_sulent © (2004-04-08 11:03) [10]

Можно, я делал такую муть, но дело в том, что трафик будет лететь как ненаю что... Есть возможность синхронизации данных парадокса по сети. Делал все через БДЕ, но это было давно и уже конкретно не помню что да как делал. Но тормоза будут когда база наберет порядком записей!
В общем делаешь общий сетевой ресурс с базой, на котый ссылаются все клиенты (правда я пробовал только на двух компах :))), устанавливаешь пути в БДЕ которые нужно (но есть одна фишка, да даже не одна, обязательно путь к базе должен быть одинаковый для всех компов). Делал я это все глючно, на серваке делал обыкновенный subst, а на клиентах подрубал сетевой диск!
И обязательно в корне программы должны висеть два файлика, вот убей не помню какие и как называются... и еще надо в БДЕ Администратор помимо одинакого пути в DataBases, еще в конфигурациях найти Drivers\Native NET DIR указать единый путь к проге и желательно BLOCK SIZE поставить поболее, чтобы побыстрее по сети работало. Затем так же в Configuration\System\INIT нужно установить LOCAL SHARE = true.

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

← →
_sulent © (2004-04-08 11:03) [10]

← →
Sergey13 © (2004-04-08 11:14) [11]

2Locker (08.04.04 10:20) [8]
2Геннадий © (08.04.04 10:47) [9]
>И мне интересно, что имелось в виду?
Я не АП конечно, но попробую.
Дело в том (в частности), что смысл и логика работы как правило подразумевает, что в 99.9% случаев одному юзеру по барабану то, что делает другой. Сложно представить, что оба редактируют один документ. Для защиты от все таки возможных коллизий в БД есть примочки типа правил целостности. Например если поле не может быть меньше 0, то БД и не даст этого сделать. А проверять каждый раз сколько там - себе дороже. Поэтому целесообразнее в программе прописывать реакцию на исключение, а не предварительную проверку.

← →
Sergey13 © (2004-04-08 11:14) [11]

← →
romeo © (2004-04-08 11:56) [12]

> _sulent © (08.04.04 11:03) [10]

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

← →
romeo © (2004-04-08 11:56) [12]

← →
_sulent © (2004-04-08 12:25) [13]

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

← →
_sulent © (2004-04-08 12:25) [13]

> _sulent © (08.04.04 12:25) [13]

Расскажу подробнее.
Данные на форме отображаются не в DBGrid"е, а "ручками" заносятся в TTreeView и TListView по результатам SQL-запроса. Там же они добавляются и редактируются - тоже путем выполения SQL-запроса.
Такая ситуация: один из юзеров изменил текст одного из Nodes в TTreeView, что вызвало обновление записи в базе. Как об этом узнать остальным и перезагрузить свои TTreeView?

← →
Lamer2 (2004-04-08 16:46) [15]

Сделай таблицу с одним полем-счетчиком, если добавляешь/удаляешь/редактируешь, то счетчик увеличивай, а на Таймер повесь проверку, типа, если счетчик увеличился, то обновить....

← →
Lamer2 (2004-04-08 16:46) [15]

> Lamer2 (08.04.04 16:46) [15]

Это мысля, однако...

← →
Locker (2004-04-08 18:30) [17]

У нас в БД есть таблица "Синхронизация" со структурой:
- Код (автоинкремент)
- ИмяТаблицы (строка)
- КлючЗаписи (тип - в зависимости от ключа; по умолчанию ключи всех таблиц - целое число-автоинкремент)

Алгоритм
Запуск:
- подсоединение к БД
- запрос из таблицы "Синхронизация" максимального "Код"а" (используется в качестве номера последней синхронизированной записи "ПоследнийКод")
- загрузка таблиц
Синхронизация (по таймеру):
- запрос из таблицы "Синхронизация" всех записей с "Код"ом" > "ПоследнегоКод"а"
- запрос из таблиц БД (по полю "ИмяТаблицы") записей с "Ключем"ом"="КлючЗаписи" и обновление таблиц в ОЗУ на полученные значения
- сохранение "Код"а" как "ПоследнегоКод"а" номера последней синхронизации

Это все лучше реализовывать при помощи отдельных компонентов-контролеров таблиц (и отдельный компонент-контролер БД).

Запрос единичных записей из таблиц, при наличии индексных полей, происходит за считанные доли секунд (на "ура"), поэтому и синхронизация происходит очень быстро. Говорю же: у нас синхронизация идет в основном потоке, и никаких тормозов (ну, разве что иногда курсор-часики мигнет в случае коллизии в сети (когда фильмы смотрят по сети))...

← →
Locker (2004-04-08 18:30) [17]

Порылся в сети, нашел это:
http://www.delphikingdom.com/asp/viewitem.asp?UrlItem=/helloworld/bdeloc.htm

Никто такого не пробовал?

> romeo © (11.04.04 01:17) [18]

Проверил это на локальной базе, используя две копии одного приложения. Работает. Изменяем в одном из них запись в таблице - вторая копия получает сообщение об изменении этой таблицы (отслеживается все на уровне сообщений Windows). A затем уже можно по выбору - или принудительно обновить данные у юзера, либо ненавязчиво подсказать ему, что он отстает от жизни, а там пусть делает что хочет - не обращает внимания или жмет кнопочку "Refresh". Элементарно можно сделать свой компонент с нужным событием.
Крутизна, короче...

Отслеживание изменения таблицы Найти похожие ветки