Люди, так как этот вопрос относится к столбцам IDENTITY и репликации слияния, если я могу попросить вас воздержаться от ответа на «использовать GUID вместо». Я прекрасно знаю о преимуществах и ограничениях обоих и использовал SQL-репликацию с CE с SQL Server 2000. Очень иногда я удивляюсь. Это такой случай.SQL Server CE, что действительно происходит с диапазонами @threshold и identity?
Это сложное описание проблемы, поэтому, пожалуйста, несите меня.
Ниже приведена выдержка https://msdn.microsoft.com/en-us/library/ms152543.aspx и это то, что я всегда понимал в отношении диапазонов идентификации и пороговых значений.
«Абоненты бегущих SQL Server Compact или предыдущие версии SQL Server назначены только основной диапазон, присвоение новых диапазонов контролируются параметром @threshold Кроме того, переиздание Абонент имеет только диапазон, указанный в @. identity_range, он должен использовать этот диапазон для локальных изменений и изменений в подписчиках, которые синхронизируются с повторно подписывающим подписчиком. Например, вы можете указать 10000 для @pub_identity_range, 500000 для @identity_range и 80% для @threshold. После 8000 вставок на Абонент (80% от 10000), издателю назначается новый диапазон. Когда назначается новый диапазон, в таблице значений идентификатора в таблице будет отсутствовать пробел. Указание более высокого порога приводит к меньшим разрывам, но система менее отказоустойчив: если Merg e Агент не может работать по какой-то причине, у Абонента может более легко закончиться идентификация ».
Если бы предполагалось, что это правда, на данный момент мы доберемся до начала моей проблемы.
Чтобы помочь пользователям, использующим наше приложение, мы используем вариацию следующего запроса, чтобы клиенты знали, что могут протестировать личность, если они продолжат работу, и инициировать синхронизацию для получения нового диапазона.
SELECT
AUTOINC_MAX, AUTOINC_NEXT, AUTOINC_MAX-AUTOINC_NEXT
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
TABLE_NAME = N'Asset'
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898 | 3080899 | 999
По оценке AUTOINC_MAX - AUTOINC_NEXT (= 999), мы можем видеть, когда мы получаем низкий по идентификаторам
В коде мы смотрим на AUTOINC_MAX - AUTOINC_MIN, который дает выделенный диапазон. Используя порог по умолчанию 80% и оставшийся диапазон, мы можем консультировать клиентов для синхронизации, если они выглядят как иссякшие.
Однако это то, о чем я думал, что это правда, на практике. Ссылаясь на детали Microsoft, приведенные выше этого предложения, выделяется «Когда назначается новый диапазон, в значениях диапазона идентификаторов в таблице будет пробел».
Я принимаю это означает следующее
Если наш пользователь имеет диапазон идентификаторов 0-1000 идентификаторов и использует идентификаторы до 801. На следующей синхронизации пользователь будет выделен следующий диапазон 1001-2000 (мы предполагаем, что один абонент для иллюстрации). В результате синхронизации следующий использованный идентификатор будет 1001, оставив зазор от 802-1000.
Во-первых, пожалуйста, дайте мне знать, если мое понимание неверно.
Во-вторых, хотя это не то, что мы видим на практике.
На практике то, что мы видим на основе вышеприведенного примера, после синхронизации и последующих вставок, является балансом идентификаторов, используемых до тех пор, пока мы полностью не расходуем исходный диапазон. THEN при расчете диапазона AUTOINC-MIN, -MAX и -NEXT обновляются до нового диапазона.Никаких дополнительных синхронизаций не произошло.
Ниже приведен пример.
В целевой таблице последний идентификатор, используемый в 3080899
Для имитации использования следующий запрос был использован
INSERT INTO Asset (lInstID, lTypeID, sUsrName, lUsrID, dCreated, dAudit, sStatus)
SELECT
lInstID, lTypeID, sUsrName, lusrID, dCreated, dAudit, sStatus
FROM
Asset
WHERE
lAssetID = 3080899
После вставки следующего значения идентификатора используемого 3080900 (как и следовало ожидать, например, AUTOINC_NEXT = 3080899, + 1 = 3080900)
Повторяем эту вставку, пока не достигнем 80% выделенного тождества.
SELECT
AUTOINC_MAX, AUTOINC_NEXT, AUTOINC_MAX-AUTOINC_NEXT
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
TABLE_NAME = N'Asset'
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898 | 3081699 | 199
Мы синхронизируем. Мы отмечаем изменения 800 подписчиков. Мы запрашиваем, и это то, что мы видим. Без предварительной синхронизации.
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898 | 3081699 | 199
Мы продолжаем вставлять, пока не нулевые идентификаторы остальные
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898 | 3081898 | 0
Один больше вставки и результаты этого
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3082898 | 3081899 | 999
Это совершенно неожиданно и вопреки , когда новый диапазон назначается, в таблице значений идентификатора в таблице будет пробел. Фактически, IDENTITY RANGE является непрерывным. Это несколько желательно, поскольку мы не теряем идентификаторы.
Я не могу найти в .SDF, где сохраняется следующий выделенный диапазон.
Я предполагаю, что это next_range_start и next_range_end из таблицы на sysmergearticles сервера, но никакой документации не может быть установлено, что выставляет эти значения в .SDF.
Если кто-то знает, что здесь происходит, я бы очень признателен.
Как можно заметить, если вы полностью расходуете этот «следующий диапазон» без синхронизации, база данных возвращает ошибку, как ожидалось.
Синхроблок сообщение об ошибке показывает 1200 новых записей, загруженных абонентом (200 из предыдущего диапазона плюс 1000 от «следующего диапазона»)
AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3083898 | 3082898 | 999
С наилучшими пожеланиями
Эндрю