Одно время передо мной стояла такая же задача. В своих попытках решить задачу в наиболее общем варианте пришел к таким выкладкам:
Реплицируемые данные можно разделить на две категории - данные которые могут привести к логическим коллизиям и данные которые НЕ могут привести к логическим коллизиям.
К первой группе относятся справочники, ко второй в основном оперативные данные.
С репликацией данных второй группы проблем не возникает (я просто разнес интервалы генерируемых первичных ключей на разных экземплярах БД), хотя ReplicaID поле так же присутствует
С первой группой несколько сложнее: поломав голову пришел к такому решению:
В таблицу кроме поля ID добавленно поле LinkTo, т.е. запись _ссылается_ на другую. В этом случае в справочнике могут присутствовать записи Ленинград, Петербург, Санкт-Петербург, St. Petersburg. Но все они будут иметь одинаковое значение LinkTo, причем значение это не принчипиально (одно из приведенных четырех). Так как писать AI разрешающий подобные конфликты мне не по зубам (и не думаю что кто нибудь в этом сильно преуспеет), я оставил этот вопрос в виде административного решения (сидит человек, который проверяет вновь введенные данные (полученные при репликации) и решает новая это запись или ссылка на уже существующую).

Как правильно заметил Сергей Тарасов (№2), репликация подразделяется на репликацию данных на уровне сервера данных, и репликацию данных на уровне бизнес-логики. И это не одно и то же.

Репликация первого рода часто решается средствами SQL-сервера. Часто достаточно первичный ключ реализовать либо как GUID, либо как набор из пары (КодСервера, КодПоследовательности).

Репликация второго рода тоже решается достаточно просто, если подумать об этом заранее. Так, идеально для объектов предусматировать отношения "идентичности". Так, пусть "Санкт-Петербург" и "Ленинград" будут разными объектами. Пусть даже два "Санкт-Петербурга", введённые одновременно в двух филиалах.
В любом случае между ними некое ответственное лицо (возможно, при поддержке аналитических алгоритмов, выбирающих достаточно интересные совпадения) может установить или разорвать отношение идентичности. Естественно, все поисковые алгоритмы должны быть соответствующим образом модифицированы.
Кстати, подобные мероприятия нужно устраивать в основном только для справочников. Обычно опреативные данные такого не требуют, операции филиалов обычно фактически разделены.

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

Делаю двунаправленную репликацию между множеством удаленных узлов. Одним выстрелом убиваю двух зайцев. Второй - это журнализация всех транзакций. Физическое удаление и измененние записей подменяется логическим - именно поэтому конфликты становятся разрешимыми. В версии MS SQL 7.0 реализовано на рекурсивных триггерах. Когда в версии 2000 устранят имеющиеся глюки, можно будет все существенно проще сделать на Instead-триггерах. Основные принципы:
1. В строках таблиц хранятся два GUID-идентификатора. Первый - уникальный идентификатор записи, второй - уникальный идентификатор ВЕРСИИ записи.
2. В каждой таблице кроме базовых полей (используемых в предметной области) заводится два набора служебных полей: а) о создании версии записи б) о ее уничтожении. Каждый из этих наборов полей содержит:
- Идентификатор пользователя, произведшего операцию (справочник пользователей реплицируется вместе со справочником удаленных узлов, на которых они регистрируются - отсюда вычисляется и удаленный узел). Пользователи могут только добавляться. Удаление пользовтаелей только логическое. Модификация имени не допускается.
- Дата/время операции
- Код рабочей станции, с которой произведена операция (справочник формируется автоматически с добавлением новых записей из триггеров при появлении новых рабочих станций - и реплицируется аналогично справочнику пользователей.
3. Правила разрешения конфликтов репликации следующие.
- Любое изменение записи имеет более высокий приоритет над ее удалением. Если запись на одном узле удалена, а на другом изменена, после двунаправленной репликации останется версия ее изменения, удаление аннулируется.
- При одновременном изменении одной и той же записи на разных узлах после двунаправленной репликации на всех узлах останется вариант более поздней модификации записи (определяется датой/временем модификации).
  Одновременно остается возможность просмотра истории модификации записи, в том числе можно отфильтовать имевшиеся конфликты репликаций (постфактум). Полностью воспроизводима информация о том, когда, какого рода произведена операция каким пользователем, сидя за каким компьютером какого удаленного узла. Пример таблицы со служебными полями приведен ниже. В нем для удобства восприятия все GUID-идентификаторы заменены целочисленными, поля с префиксом c_ подразумевают "создание редакции" (creation), поля с префиксом k_ подразумевают уничтожение редакции (kill). WKS - Worstation - идентификатор рабочей станции, с которого сделана операция. EdID - уникальный идентификатор модификации записи - используется при репликации как RowGUID. Из предметных полей в таблице присутствует только одно - Name - наименование организации:

RecID EdID c_User c_Time c_WKS k_User k_Time k_WKS Name
-------------------------------------------------------------------
1      1      1  01/01/00  5    2  05/01/00  8  Рога и копыта
1      2      2  05/01/00  8    3  10/01/00  7  ЗАО Рога и копыта
1      3      3  10/01/00  7  Null  Null    Null ЗАО Копыта и рога
2      4      1  02/01/00  5    2  06/01/00  8  НПО АОЗТ
2      5      5  06/01/00  8    3  11/01/00  7  НПО АЗОТ

В данный момент (не удивляйтесь) в таблице всего 1 актуальная запись с RecID=1, EdID=3. Вообще в ней побывало всего две записи (у одной RecID=1, у второй RecID=2). Первую запись ввел 01/01/00 пользователь 1 со станции 5, присвоив Name="Рога и копыта". 05/01/00 пользователь 2 со станции 7 исправил это наименование на "ЗАО Рога и копыта". 10/01/00 пользователь 3 еще раз изменил запись на "ЗАО Копыта и рога".
Вторая запись была создана 02/01/00 пользователем 1 со станции 5 с названием "НПП АОЗТ". 06/01/00 пользователь 2 со станции 7 изменил это название на "НПП АЗОТ". 11/01/00 пользователь 3 со станции 7 удалил эту запись.
  Репликация используется Merge. Физические конфиликты устраняются стандартно - приоритетами. Для конфликтов одновременного изменения записей приоритеты не существенны. Обратите внимание на то, что служебная информация дублируется в двух смежных редакциях одной логической записи (с одинаковым RecID) - один раз она прописывается в полях уничтожения старой редакции, второй раз - в полях создания новой редакции записи. Не соответствие этих полей говорит о конфликте репликации. Кофликты репликации могут привести к появлению в таблице одновременно двух и более записей, имеющих Null в служебных полях уничтожения (с префиксом k_). Взгляд, отфильтровывающий только актуальные записи выбирает из таких записей только одну с наиболее поздней датой/временем создания.

У себя в компании, когда мы делали независимые (удаленные) рабочие места, то использовался почтовый метод синхронизации.
Каждое место имеет дерево зависимостей одной базы от другой.
Когда транзация завершаеться, то АРМ посылает почтовую рассылку с массивом операций нужным агентам, добавить, удалить или заменить рекорд каждые N -секунд - минут.

Все получатели обязаны отчитаться в срок о проведении транзакций, при недополучении от кого-то повторная отсылка.

Для автогенерации пользуюсь sql командой


//  SELECT Max(ID) AS tempCount FROM table;

long __fastcall TFormDatabase::MaxNumber(TADOQuery *qr, String field, String table, String where)
{
  long maxnum = 0;
  try
  {
      where = where.IsEmpty() ? String("") : String(" WHERE " + where);
      String sql = "SELECT " + field + " FROM "+ table + where + ";";
      _Query(qr, sql);
      if( !qr->Eof )
      {
        sql = "SELECT Max(" + field + ") AS tempCount FROM "+ table + where + ";";
        _Query(qr, sql);
        maxnum = qr->FieldByName("tempCount")->AsInteger;
      }
      qr->Close();
  }
  catch(...){return 0L;}
  return maxnum;
}

// все записи должны иметь поле CRC - где храниться CRC32 каждой записи - и для секьюрити полезно и для синхронизации тоже.

В свете технологии .NET в качестве почтового формата используеться XML - весьма удобная форма для мелких (до 1 Мб) рассылок данных.

2 All
Я в одном из предыдущих сообщений обещал выслать руководство пользователя по модулю "Офис-филиал". Так как уже пришло несколько писем с такой просьбой, то я выложил полное руководство пользователя по КИС Ultima-S
http://www.arbinada.com/projects.html
Там есть в том числе и описание "Офис-филиал".
Не панацея, конечно, но может кому поможет в его конкретном случае.

И еще все-таки советую почитать архивы эхи ФИДО su.dbms так как то же самое там уже обсуждалось.
архив на
http://www.deja.com/usenet
конференция fido7.su.dbms

а мы шлепаем PRIMARY KEY c определенным шагом (в нашем случае 100)
и у каждой базы свое окончание для Id-ов. Просто и со вкусом.

2 swame
Это точно, я тоже заметил :)
--

2 Igor
Что касается проблемы с UNIQUE (когда на комбинацию полей наложено UNIQUE и при попытке синхронизации выясняется, что имеем >1 записи с данными значениями), то чёткое следование правилам реляционных БД здесь выручает (не помню уж какого рода эта нормализация) -- две записи с одинаковыми атрибутами (одинаковым UNIQUE-набором) описывают одинаковую сущность, след-но дубликат без душевных мук удаляется. Лучше всего, конечно, когда UNIQUE наложен на всю комбинацию полей (исключая первичный ключ). Т.е., реально, это вопрос грамотного проектирования БД. Пример с Ивановым грешит той же проблемой -- нет UNIQUE-ограничения. Надо добиться уникальной идентификации. Как -- вопрос второй :), но придумать можно. Даже не спрашивая паспорт, что тоже не панацея.
Правда здесь встаёт проблема, чтобы осталась запись с общим кодом... Н-да... С дискетами морока... А вот если сеанс двусторонней связи, то ничего принципиально сложного.

Все это конечно здорово, но зачем усложнать себе жизнь? Я всегда для каждой конкретной задачи выбираю нужный вид синхнонизации. Это в большенисве случев означает принятье адменестративных мер для создания уникальных данных на местах. Или изменение логической схемы обработки информации. Других уневерсальных и стопроцентно работяющих способов нет и быть неможет(всегда найдутся исключения из правила) по определению.

tips&triks для читающих статью на
http://iamhere.infodom.ru
нажмите Ctrl-A и вы сможете прочитать статью не сломав глаза!

ПАРДОН ЗА НАЗОЙЛИВОСТЬ, но еще раз...

...приглашаю всех заинтересовавшихся зайти ко мне на страничку
http://iamhere.infodom.ru

Там есть начало статьи про синхронизацию.

Когда допишу - правда не знаю, работы много