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

Для синхронизации БД я в каждую оперативную таблицу в Primary Key добавил код удаленного офиса (в моем случае он два поля - код предприятия+код подразделения). Таким образом с каждого рабочего места можно читать
любые данные, а писать(добавлять) только в свои. Справочники ведутся централизовано. Удаленные офисы обмениваются данными между собой и головным офисом. Архитектура базы данных - звезда.

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

синхронизировать базы? маска? а если там более 100000 записей

думаю нужно немного менять структуру решения

1.можно создавать mirror файлы указатели изменений и сливать частички
баз одним школьным SQL запросом, при этом желательно знать кто мастер
а кто слэйв, если равнозначные - апдейт должен быть дуплексным и зависеть например от времени послнднего изм - все это реально

2 можно сделать I-net и перевести это все в дискретный оффлайн


вообще конечно желательно уточнить - почему нет возможности работать кооперативно в сети

мы тоже как-то решали подобную проблему. причем для парадокса (да, смех вполне уместен). и делали это следующим образом


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


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


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


для пересылки объект превращал себя в строку (отдаленно похожую на лисп-код), а на месте самовостанавливался.


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


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


________________


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

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

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

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

Если применяются суррогатные ключи (автоинкрементные целочисленные поля), то уникальным может быть составной ключ ServerID + ObjectID.
Однако, проблема остается, если например, на разных серверах создали в перерыве между репликациями пункт "Санкт-Петербург" в справочнике городов. Решается это с трудом либо административными мерами (централизованное ведение нормативно-справочной информации) либо опять же эвристическими анализаторами семантики (распознавание нескольких "Санкт-Петербургов" в разных физических базах и определение, что "Петербург" и "Ленинград" суть одно и то же).
Если интересно, я могу по email выслать руководство пользователя, которое мы разрабатывали года 3 назад для модуля "Офис-филиал" в проекте системы автоматизации, может чего путного найдешь?

Это просто.
Каждой копии программы присваивается уникальный номер (нпример, четырехзначный). Каждая создаваемая транзакция нумируется уникально в пределах одной копии. При синхронизации используется комбинированный индекс номер копии и номер транзакции. Каждый желающий синхронизироваться просматривает все записи с номером, больше последнего имеющегося в своей базе данных чужого номера копии программы. Если у меня последний номер записи для программы, с которой я сейчас синхронизируюсь - 25, то я у нее запрошу всё, что больше 25. И так - с каждой копией.
Так же решается и проблема счетчиков. У каждой копии - свой префикс счетчика. Заодно обеспечивается точная трассировка источника записи.
Проблема сложности синхронизации с несколькими копиями просто не стоит.
Штамп времени не имеет значения.

Я с этой проблемкой воюю уже третий месяц (теперь моя любимая песня - "Я сошла с ума")
Придумал несколько направлений, но по всем все-равно пришел в тупик
1) пересылать все базы и по идентификаторам записей строить маску изменений для центральной базы данных. Но если у клента №3 не сделали вовремя обратную синхронизацию (по какой-то причине). То в следующую синхронизацию отсутствие изменения будет воспринято как новое обратное изменение
2) при работе все измения записывать в журнал. Но, во-первых, встает серьезная проблема журнализации (формат, место хранения, трассировка, накопление и тп). Во-вторых, трудно определить непрошедшие транзакции и они могут "выпасть" из данных
Много еще других неуказанных проблем. в частности - идентификация записи. Идентификатор должен быть уникальныи на всем пространстве данных (на всех филиалах вместе) и в течение всего времени жизни объекта (записи по какому-то условию могут отрезаться)
Для меня это насущная проблема, тк начальство давит сильно, заявля, что это наверняка просто
Можем поработать над проблемой вместе

Не буду врать, так как с этим не разбирался, но как я понял нечто подобное есть в JDataStore Server от Borland JBuilder 4.0 (во всяком случае они так пишут).