Исходная ситуация :

1. Есть распределенная БД. Связь между отдельными БД поддерживается по е-мейлу, дискетами (пересылка пачек данных самодельным репликатором)
2. Данные из отдельных БД должны без коллизий, обусловленных одинаковыми PK, сливаться в любую из этих автономных БД.
3. Во всех случаях используется Windows-платформа.

Требуется обеспечить уникальность PK записей в масштабе всей распределенной БД.

Известные решения :
1. Разнесение диапазонов идентификаторов записей путем индивидуальной инициализации генераторов для каждой автономной БД.
2. Привлечение особого (уникального для каждой БД) числового "кода БД", который также "оседает" в PK.

Недостатки этих решений :
1. в жестком варианте (пока администратор не даст добро задача не будет работать) тратится много времени на ожидание действий админа, доставку регистрационного ключа и появляется дополнительная "головная боль" с централизованным учетом диапазонов/кодов
2. в мягком варианте (когда пользователи сами могут взять и применить настройки из разрешенных диапазонов) возникают другие проблемы :
- разные подразделения "выезжают" за пределы разрешенных для использования диапазонов и соответственно могут пересечься.
- используют более одной автономной базы под одним "кодом БД"
- поработав в базе под "кодом"=Х отправляют из нее данные в другие базы, после чего базу убивают, восстанавливают из архива чистую базу и присваивают ей опять "код БД"=Х

Поэтому к первоначальной фомулировке задачи я добавлю автоматически поддерживаемая уникальность PK (т.е. без какого-либо участия человека в настройке системы)

Подумав, я заключил, что достаточным основанием для уникальности служит тезис о невозможности работы одного и того же оборудования в разных местах (подразделениях/компьютерах) в одно и то же время. Значит привязку нужно делать к железу и времени.

Время : select current_timestamp from rdb$database
Железо : VolumeSerialNo из API-шной GetVolumeInformation

Обе эти величины представимы в виде 4-байтового числа, а значит, в состав PK таблиц требуется ввести 2 дополнительные колонки integer. Дальше уже дело техники и триггеров на вставку...

Есть ли еще не такие "корявые" решения как у меня?

От привязки ко времени создании записи нельзя отказываться и при использовании GUID. Навскидку приведу 2 ситуации :

1. Компьютер работал под задачей в одном подразделении, после чего его целиком передали в другое подразделение и скопировали на него другую автономную базу.
2. поработав в базе пользователь отправляет из нее данные в другие базы, после чего базу убивает, восстанавливает из архива чистую БД и продолжает работать в ней.

В обоих случаях получается, что файлы БД эксплуатировались разные, а GUID один и тот же.

А какой функцией он генерится?

И разве он не будет больше 8 байтов?
Естесственно, чем больше, тем хуже для производительности IB.