Vadim:
<<<Господа, не надо выдумывать велосипед. Внимательно посмотрите вокруг и ВЫ найдете нужное решение. Конкретно один из вариантов: СУБД Sybase SQL Anywhere начиная с версии 5.0 (Сейчас Adaptive Server Anywhere). Прекрасный, надежный, промышленный вариант решения ваших проблем.>>>

Ну-ну... Ну и что этот замечательный репликатор сделает, если я в одной БД припишу к главной записи дочернюю, а в другой БД - удалю эту главную? Коллизию покажет?... И тебе придется посадить понимающего человека, который будет эти коллизии исправлять...  Или у вас все кроме одной БД read-only? Тогда ЛЮБОЙ рапликатор нормально справится...

ИМХО нормального репликатора для двусторонней репликации не будет никогда - я недавно почитал доки по репликации в DB2 - вот уж кто БД занимается с незапамятных времен - у них там все далеко не шоколадно.....

2 Nick
заводим служебную таблицу-указатель изменений
(можно и просто mirror файл)
а далее простой SQL

а вообще самый оптимум предложен Flx'ом - это реляционный подход !!!!

TO: Сергей Тарасов
Интересно, какой анализ семантики может быть, если в справочниках наименования вводятся с грамматическими ошибками, а проверка орфографии невозможна в принципе? Например в справочнике ассортимента 10 юзеров любой иностранный товар введут 10 раз по-разному, причём в половине случаев в русской транслитеризации или смешав русские и английские буквы, не говоря уж про сложные составные наименования.
Не, по-моему надо лучше работать над структурой данных и выделять однонаправленные потоки, а всё остальное легче и быстрее решить на организационном уровне. Против человеческого ФАКтора помогает только другой человеческий фактор.

To Vadim
Любимое занятие российских программистов-выдумывать велосипед. Не мешайте им.

Vadim
Удобство удобством, но Вы говорите о физической репликации. А как в вашей системе анализируется семантика? (Тот же пример со вводом Петербургом-Ленинградом в разных физических базах)

Господа, не надо выдумывать велосипед. Внимательно посмотрите вокруг и ВЫ найдете нужное решение. Конкретно один из вариантов: СУБД Sybase SQL Anywhere начиная с версии 5.0 (Сейчас Adaptive Server Anywhere). Прекрасный, надежный, промышленный вариант решения ваших проблем. Заложенный в этот сервер решение SQL Remote (репликация данных по низкоскоростным линиям)имеет все что нужно, протоколы от FTP до Lotus Notes, разбор полетов в момент слияния на уровне тригеров, репликация части таблиц, а можно по условию, три режима репликации: по требованию, shedule вариант или через промежуток времени. Практически все схемы репликации, 1-1, 1-много, много-1, "круговая". Истинный (чистый)SQL server на всех практически платформах (все Win.., Novell, QNX)Мы его эксплуатировали в режиме репликации около двух лет. Удаленная точка, круглые сутки в две смены, модем 19200, ~500 записей в день, сервер NT4 + Exhange (для репликации) все работало честно, ни разу не упало, не пропало ни одной записи. Потом все переделали на Midas3 стало быстрее и проще. Но это было потом, сперва были Delphi2. Что касается двойных первичных ключей, на первый момент это кажется верно (и у нас так было), но это очень неудобно в работе и при администрировании, рекомендую использовать в случае репликации GUID в качестве первичного ключа.

мы тоже решили такую проблему.
структура подразделений была такая : Главный офис - Обласные управления - Подразделения обласных управлений.
Схема СУБД везде одинакова. Синхронизация строилась на основе обмена файлами выгрузок. Можно по обмениватся или через мыло или через дискетки(что очень важно в связи с качеством линий в регионах). Основная идея - 2ой ключ в каждой таблице (ID, INST) INST - номер структурного подразделения из общего справочника.
Для хранения счетчиков делается справочник с названием сечика, номером инстанции, значением.

На мой взгляд наиболее сложная проблема - КАК ВЫБРАТЬ ИЗ БАЗЫ ТОЛЬКО ИЗМЕНЕНЫЕ ДАННЫЕ.
У нас было поще - мы запретили всякие делиты и апдейты(В основном это было связано с возможностью отслеживания всей истории модификации данных)

Мы решили подобную задачу так (метод похож на предложенный AnorAglar'oм):

Во всех таблицах нуждающихся в синхронизации обязательно присутствуют поля:
1) RemoteId - номер БД (1-в гл.офисе, 2- на 1-ом удал. складе, 3- на 2-ом и т.д.)
2) Id - автоинкремент, уник номер для данной таблицы
3) LastChangeDate - дата последнего изменения записи (есть и поле с ФИО того кто менял, но это не в тему)
4) LastSyncDate - дата последней синхронизации для этой записи.

Алгоритм:

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

2) Из местной БД выбираются записи (по очереди для каждой таблицы), у которых дата последнего изменения позднее, чем дата синхронизации  _И_  записи, у которых нет даты синхронизации (т.е. новые).
Для этих записей ищется аналог в Главной БД (в соответствующих таблицах) по ключу "RemoteId;Id": если в Главной БД дата изменения не позднее даты синхронизации (т.е. не изменялась) - тогда запись из Местной заменяет запись в Главной. А если в Главной БД дата последнего изменения позднее даты синхронизации (т.е. и здесь ее тоже изменили), то решать какую оставить будет Юзер ответственный за это: список таких записей - в таблицу конфликтов и пользователю на решение.
Понятно, новые записи - просто подливаются из местной в главную.

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

-----------------
Рад, если кому-то поможет или наведет на дельные мысли.

Мы решили подобную задачу так (метод похож на предложенный AnorAglar'oм):

Во всех таблицах нуждающихся в синхронизации обязательно присутствуют поля:
1) RemoteId - номер БД (1-в гл.офисе, 2- на 1-ом удал. складе, 3- на 2-ом и т.д.)
2) Id - автоинкремент, уник номер для данной таблицы
3) LastChangeDate - дата последнего изменения записи (есть и поле с ФИО того кто менял, но это не в тему)
4) LastSyncDate - дата последней синхронизации для этой записи.

Алгоритм:

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

2) Из местной БД выбираются записи (по очереди для каждой таблицы), у которых дата последнего изменения позднее, чем дата синхронизации  _И_  записи, у которых нет даты синхронизации (т.е. новые).
Для этих записей ищется аналог в Главной БД (в соответствующих таблицах) по ключу "RemoteId;Id": если в Главной БД дата изменения не позднее даты синхронизации (т.е. не изменялась) - тогда запись из Местной заменяет запись в Главной. А если в Главной БД дата последнего изменения позднее даты синхронизации (т.е. и здесь ее тоже изменили), то решать какую оставить будет Юзер ответственный за это: список таких записей - в таблицу конфликтов и пользователю на решение.
Понятно, новые записи - просто подливаются из местной в главную.

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

-----------------
Рад, если кому-то поможет или наведет на дельные мысли.

Когда я занимался 1С, то обращал внимание что там это реализовано.
Никто не интересовался как?