Для начала разобъем проблему на два этапа:
 
1. "Мало того, один и тот же идентификатор в разных базах может быть отдан разным объектам" [/i].
2. Реализация механизма.
 
1. Если в качестве OID (т.е. уникального идентификатора) использовать некий автоинкрементный счетчик, то действительно можно столкнуться с вариантом, когда в двух разных базах будет создано два разных действия с одним OID. Но зачем привязываться к счетчику? Не проще ли генгерить значение OID в зависимости от какого-либо постоянно меняющегося значения (системного таймера, например), + уникальный (в той же мере) идентификатор самой базы.
 
Преобразовать по какой-либо формуле значение текущей даты-времени, добавить идентификатор базы (да хоть серийный номер диска на котором лежит база) - вот и уникальный идентификатор в пределах 100 лет.
 
2. Собственно реализация зависит скорее от желания автора, но особых проблем здесь не видно.
Проблема с OID, проблема с определением "старшинства" записи (т.е. какая из двух конфликтующих записей верна)... и т.д.
 
Хотелось бы для начала иметь хотя-бы возможность "сращивания" двух баз с полной заменой каких-то счетов (смотри прошлое письмо).
 
Формат файла не может стоять преградой, где-то в 2001-2002 годах я приводил пример "изучения" собствено формата базы Cash`а. (см мыло).
 
Да и "внешнее управление" ввести можно, если уж серьезно взяться за проблему с точки зрения пользователя.
 
Dervish: На самом деле фраза "Мало того..." не была ключевой фразой моего сообщения. Основная идея: реализовать полноценную синхронизацию без файла соответствия, по-моему, будет почти невозможным. Но если для синхронизации нужен файл соответствия, то возникает второй вопрос: а где же его хранить? Опять же, в случае, когда должны синхронизироваться N баз данных (с выделением одной мастер-базы) надо бы создавать и поддерживать N-1 файлов соответствия.
 
Действительно, можно и не использовать счётчик. Можно, в конце концов GUID использовать, вроде как нам гарантировали его уникальность. Но основная сложность как раз в том, чтобы чётко обозначать соответствие что вот этот объект (неважно с каким идентификатором) в одной базе хранится в другой уже вот с этим идентификатором. И проблема осложняется тем, что, как я показал выше, для операций невозможно указать набор параметров, которые бы чётко отделяли одну операцию от другой. А значит, конфликты просто невозможны, значит, всё сливаем в одну кучу и только потом (вручную!) разбираемся, что в ней дублируется, а что нет.
 
Не нашёл я в мыле (хотя храню всю переписку) "изучения" формата базы первой версии программы (может быть потерялось?). Если не затруднит, повторите ещё раз.