Хотелось бы подчеркнуть два момента из ответа:
1. Можно, в конце концов GUID использовать, вроде как нам гарантировали его уникальность.
2. чётко обозначать соответствие что вот этот объект (неважно с каким идентификатором) в одной базе хранится в другой уже вот с этим идентификатором.
 
Теперь рассмотрим ситуацию. Скажем я имею базу с одной записью "зарплата 1000р" (ID=232967). Копирую её себе на ноут, и ухожу на работу. На работе я заношу запись "завтрак 10р" (ID=468045).
Пока я был на работе жена в домашний компьютер занесла запись "продукты на обед" (ID=288576).
 
Теперь в результате мы имеем две базы:
 
Моя: ID=232967, ID=468045
Дом: ID=232967, ID=288576
 
Прихожу я домой и говорю "синхронизировать".
В результате синхронизации получаю базу:
ID=232967, ID=468045, ID=288576.
 
Конфликтующих записей нет, т.к. ID=232967 не менялась. Если записи ID=232967 отличаются в разных файлах, то смотрим у какой из них более свежее время изменения, ту и сохраняем.
 
При изменении записи ID меняться не должен.
 
см. часть вторую :-)
 
Dervish: Я немного "причесал" стиль: цитаты из моего текста все сделал курсивом, а то, что вы хотели выделить - выделил полужирным шрифтом. Текст не изменял, так что, надеюсь, вы на меня не в обиде.
 
По сути: вроде как всё должно работать. Но мне всё равно трудновато отказаться от привычных стереотипов. Давайте я немного подумаю, так как вы меня немного загоняете в тупик. Дело в том, что во второй версии я уже сделал уникальные идентификаторы (ID), но они назначаются по-порядку. И, увы, по ряду соображений я не могу изменить это. Остаётся одно: добавить дополнительное поле "id для синхронизации", если только так. Благо, вторая версия базы будет позволять легко наращивать поля в базе.