И еще одно ограничение которое вводит SQL Server Compact 3.5 он не поддерживает хранимые процедуры или представления. Так что данный вариант отпадает, почти все запросы из БД делаются StoreProc.
Здравствуйте, ЛёХыЧ, Вы писали:
ЛёХ>Раскажи общий смысал реализации системы.
Это школьный документооборот. Общий смысл таков, все данные заполняются в школах и стекаются в краевой центр через районные базы. Т.е. трехуровневая схема: школа обменивается репликами с роно, роно с краем. В другую сторону данных идет совсем мало: обновление справочников, данные по ученикам которые прибыли из других школ. В итоге в крае получается общая картина по всем ученикам, учителям, учебным планам, приказам. Таблиц 200 или больше, я уже не помню. К системе предъявлялись достаточно жесткие требования по отказам т.к. раз в год формируется туева хуча отчетов по всем данным. Естественно выпадение даже одной школы из репликации (на начало работы их в крае было более 1300) недопустимо. Ибо цифры сразу поплывут и какой-то район недополучит денег например. Поэтому, а еще потому, что бывают моменты, когда до некоторых школ только вертолетом и по рации

репликация стала самой неприхотливая к каналам связи, построена на сообщениях.
Как все устроено: каждая база получает диапазон идентификаторов которого теоретически ей хватит лет на тыщу. Все записи создаются с ключами по возрастанию из этого диапазона. На каждую таблицу вешаются CUD триггеры которые записывают айдишник и действие в таблицу лога (лог тоже с этим айдишником). Еще есть таблица соседних баз в которой хранится достоверно известный максимальный принятый ей айдишник записи лога.
Формируем посылку так: выбираем все записи лога айдишник которых больше того известного, пихаем в пакет все записи у которых в логе стоит создание или изменение. Ну и записываем айдишники удаленных записей. К посылке прикладываем максимальный принятый от той базы ключ, когда она его получит — запишет в свою таблицу соседних баз в нашей строке.
Самый геморой при приеме связан с отсутствием в фаерберде констрейнтов которые умеют проверяться при комите (deffered). И тем фактом, что констрейнты нельзя прибить или создать в дмл транзакции. Посему пришлось писать алгоритм разруливания зависимостей, который выстраивает данные в нужном порядке. После этого данные соотвественно вставляются, обновляются и удаляются.
Все возможные конфликты пресекались на уровне БЛ либо ресолвились автоматом в стиле "последний прав".
Как-то так.