На самом деле не совсем синхронизация, поскольку в этой схеме не будет конфликтов.
Предыстория, есть программа на VB6(с корнями глубоко в прошлом) и на Access. Сейчас программа полностью переписывается под .Net4.0 со всеми наворотами. Но новая версия опаздывает, и потому нужно чтобы версия VB6 имела возможность работать параллельно с .Net, который будет использовать SQLExpress2008
Проблема в том что старая версия использовала систему обновления данных восходящую еще ко временам текстовых файлов на дискетах, и сменила только способ доставки этих текстовых файлов...
Задача.
Три сотни клиентов с локальными базами, один центральный сервер, клиенты подключаются очень нерегулярно(в течении года), актуальность обновления не критична.
Данные (таблицы) трех групп - глобальные (общие для всех клиентов, изменяются ОДНИМ администратором), региональные (изменяются ОДНИМ ответственным в каждом регионе) и клиентские (сохраняются в центральный сервер, но их там никто не меняет)
С такими ограничениями необходимости разрешать конфликты вроде бы нет.
Потому была выдвинута идея простого способа обновлять данные - по логу.
Иначе говоря, в функции, которая выполняет запрос, каждый запрос не только исполняется, но и сохраняется в таблицу в виде (ID int,Request string).
При "синхронизации" админ досылает на сервер новые рекеты, а юзеры при подключении получают рекеты с новыми айдишниками и применяют их. Так же админ исполняет запросы на центральном сервере, чтобы иметь там актуальную базу, и не портить старый механизм обновления.
Способ странный, но он много проще в реализации чем, например, добавлять в каждую таблицу дату обновления-удаления, и много легче по ресурсам(прежде всего сети) чем настоящая синхронизация(массивы данных могут быть приличными, до полумиллиона записей).
Я, может быть по неопытности, не вижу минусов в такой реализации, но не нашел нигде упоминаний такого способа, поэтому хочу спросить у знающих людей - в чем может быть подвох?

АнатоЛой,

1. Последовательность обеспечивается ID, иначе упадем на foreign_key. Запросы будут выполнятся просто по возрастанию ID, удаления не предусмотрено. Клиенты друг на друга не влияют, а вот порядок обновления Глобальные->Региональные->Клиентские строгий, там уже зависимости, но опять же - не должно оставаться возможности его нарушить.

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

По сложным запросом не совсем понял, имеется ввиду вычисления на стороне сервера? Таких запросов вроде бы нету.

И спасибо за ссылку, видимо не так искал :)

ARTURV,

С такими ценами, да при существующей инфраструктуре...
И вам приятного дня.