Крис прав, когда говорит, что (1) вам не нужны GUIDS для репликации слиянием и (2) существует только один тип GUID, но вы должны знать, что:
- GUIDS могут генерироваться по разным правилам. Вы можете проверить это здесь
- При настройке репликации SQL будет систематически добавлять GUID
(генерируется как newsequentialid) для
каждая таблица, если она еще не
существует и назовет его
rowguid. Конечно, если у вас уже есть такой GUID / newSequentialId в каждой таблице, SQL будет использовать его. Но я не советую вам «смешивать» GUID репликации с PK GUID: вы можете объявить все ваши первичные ключи типа GUID как «newSequentialIds», но (a) тогда вы потеряете возможность генерировать значения GUID на стороне клиента - см. ниже - и (б) ваши ПК будут «предсказуемыми», и эта идея заставляет меня чувствовать себя некомфортно ...
- Хранение целых чисел автоинкремента и управление их диапазоном посредством репликации означает большие накладные расходы (необходимо выделить диапазоны для каждой таблицы / каждой публикации) и потенциальный источник конфликтов при репликации из разных источников.
- Более того, некоторые ошибки SQL, такие как this , характерные для распределения диапазонов, все еще не решены должным образом: применение накопительного пакета 5 не решило нашу проблему, и нам пришлось искать другой способ перезапустить наш процессы репликации.
- В любом случае, я глубоко убежден, что переключение с целых чисел на GUID в качестве первичных ключей является обязательным. Для этого есть много причин, и одна из них связана с управлением диапазоном в качестве потенциального источника для сессий головокружения и ночных проблем.
Что касается перехода с целых чисел на GUIDS, я советую вам написать пошаговый модуль, который будет:
- Сделайте резервную копию всех существующих таблиц перед их изменением
- Добавить поле GUID для каждой таблицы
- Добавить соответствующие поля FK, где запрошено
- Обновление полей FK с помощью представлений, построенных на основе существующих отношений (построенных на целочисленных полях)
- разрыв отношений
- Изменить PK с целочисленных полей на поля GUID
- Воссоздать отношения
Не торопитесь, чтобы написать этот код. Вы будете использовать его много раз, прежде чем он будет работать правильно. Вы должны получить прибыль от объекта DAO, таблиц, индексов и т. Д. Имейте в виду, что вы всегда должны иметь возможность вернуться к начальной точке, поэтому не забывайте о начальном процессе резервного копирования.
А как насчет манипулирования GUID из VBA? Об этом нужно знать несколько вещей:
- GUID типа Variant
- Можно и просто сгенерировать GUID в качестве первичного ключа на стороне клиента приложения, как я однажды предложил здесь .
- При попытке получить значение GUID
из элемента управления в форме (обычно в виде связанного поля в выпадающем списке) вы получите «?????», но никакого значения. Вы должны обратиться к значению поля в наборе записей, чтобы получить правильные данные. Вы можете открыть такую форму в своем приложении, перейти к окну «немедленное» и попробовать это:
? myForm.myControl
?????
? myForm.recordset.fields("myFieldName")
{000581EB-9CBF-418C-A2D9-5A7141A686CC}
- Возможно, вам придется преобразовывать направляющие в строки при навигации по наборам записей с помощью выражений, таких как recordset.findfirst:
myFirstRecordset.FindFirst "stringFromGUID(myGuidId) = " & StringFromGUID(mySecondRecordset.Fields("myGuidId").Value)