Самое простое что сейчас можно сделать без головняков, это написать свой Update и Merge.

Вручную в цикле прокрутить записи ds2 и вставить отсутствующие в ds1. Так как у них DataRowState будет Added. Вернуть их методом changedDataSet = GetChanges(DataRowState.Added) и кинуть в свой Update. В котором
в цикле пробегать по записям changedDataSet и данные передавать хранимой процедуре в БД1. А в этой ХП заложить всю логику: например в начале пытаться вставить, а если запись уже есть то обновить (как обновлять тоже можно решить здесь) или любую другую логику все уже дело техники.

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

По поводу Merge он просто заменяет такие проверки.
Может он и делает это супероптиизационным способом но и на милионнах записей Merge умрет, а представь какой DataSet будет в этом случае ведь по сути создание DataSet влечет за собой создание массы объектов DataTable, DataColumn, DataRow и т.д.

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

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

А в вашем случае надо делать репликацию между БД1 и БД2.
Вопрос надо задавать в форуме MS SQL если вы используете MS SQL.

То что у тебя Access сняло бы многие предложения от нас по поводу ХП, репликации и т.д. Это как раз тот случай когда чем больше скажешь тем раньше решишь проблему.

Вообще задачу синхронизации в твоем случае можно решить использую DataReader (как наиболее производительный класс), не загружая все данные в отсоединенный кэш (в данном случае DataSet). Ну да ладно с DataReaderом придется все делать ручками. Тут еще полно различных камней но все они связаны с тем что все таки для подобной задачи надо поднимать СУБД.

Если же все таки исползовать DataSet тем более у тебя продвижения в этом плане. Предлагаю все таки задуматься что когда нибудь ты не сможешь загрузить в него всё, и как вариант в таком случае это работать с данными порционно. (можно просто за последний период какой либо - я не знаю это зависит от задачи)

Теперь к вопросу как избавиться от Deleted
Для этого можешь для merge из второго Dataset брать все записи кроме удаленных например так

> MS SQL поддерживает репликацию с гетерогенных источников. Настройте репликацию и не мучайтесь. Поиск по форуму MS SQL поможет.

Зачем же так с MS SQL извращаться. Если уж начать поднимать MS SQL то сражу делать все по уму. Все пользователи будут работать с одной БД размещенной на MS SQL. Если accessовский интерфейс нужен, то существующий переделать в adp проект.

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

Что касается "все по уму" то ИМХО Идеальный вариант : одна предметная область - одна база данных. База данных должна обеспечивать ЦЕЛОСТНОСТЬ и ДОСТОВЕРНОСТЬ информации. Поэтому возлагать на клиента (даже если это и в его интересах) задачи синхронизации данных считаю не правильным.
Такие локальные средства как MS Access, FoxPro не считаю системами управления базами данных (хотя последним занимался очень долго и плотно, начиная с VFP 2.6 под DOS). Но в тоже время существует множество успешных проектов выполненных этими или подобными средствами. И такие средства все еще актуальны и ИМХО будут востребованы всегда. Поэтому рубить шашкой (предлагать Oracle Application, SAP R/3 :-) ) особо не хочется да и не имею права.

Что касается вашей задачи.
Ведь главное это достижение цели (хотя и в будущее тоже неплохо заглянуть). Если у вас все получилось и результат устраивает заказчика(или надо внушить заказчику что это то что ему надо :-) ) - значит все отлично. Единственное применительно использования двух DataSet я бы подумал о порционной обработке данных. То есть загрузки данных для синхронизации по частям или например только за последний период (считая или добиваясь чтобы предыдущие периоды были закрыты и синхронизированны)