Что вы делаете, когда ваш первичный ключ переполняется?

У нас есть таблица с auto-increment int основным ключом, максимальное значение которого теперь находится на пределе для типа T-SQL int. Когда мы пытаемся повторно засеять таблицу (потому что в ключах есть большие пробелы, нигде не хватает строк, как максимальное значение int), это как-то продолжает получать reset до значения max int.

Очевидно, это вызывает серьезные проблемы. ПК никогда не должен был получать это значение, и изменение типа данных было бы большой задачей. Повторного посева должно быть достаточно, но оно не работает!

Как он может продолжать получать reset?

Изменить: чтобы уточнить ситуацию, этот запрос SELECT MIN(CategoryID), MAX(CategoryID) FROM dbo.tblCategories возвращает -2147483647, 2147483647... означает, что существуют фактические значения PK при минимальном и максимальном значениях типа int.

Ответ 1

Вы можете "переустановить" таблицу, чтобы столбец следующего назначения был меньше текущего максимального значения в таблице. Однако любой подзадачный DBCC CHECKIDENT будет reset внутренний счетчик обратно к максимальному значению, которое в настоящее время находится в столбце. Возможно, откуда приходит reset? И, конечно, вставка, в конечном счете, попадет в дублирующее значение, в результате чего в "Интересные времена" появится команда поддержки производства.

В общем, у вас проблемы. Я рекомендую обработать одноразовый script, чтобы удалить /reset значения идентификатора uber-high. Обновление строк (и всех связанных значений внешнего ключа) является одним из вариантов, хотя это связано с необходимостью отключить ограничения внешнего ключа, и я не знаю, что все остальное, поэтому я бы не рекомендовал его. Другим было бы создание точных копий всех данных для элементов с высоким идентификатором, используя более прагматические значения идентификатора, а затем удалять исходные записи. Это взлом, но это приведет к значительно более удобной базе данных.

О, и отследите людей, которые ввели эти высокие значения id и, по крайней мере, отменили их права доступа к базе данных.

Ответ 2

Я был вовлечен в проект, у которого была аналогичная проблема, хотя в нашем случае кто-то выбрал поле с 4-значным номером в качестве первичного ключа, который вроде бы не работал, поскольку мы подошли к 9999 записям...

В нашем случае мы создали новый столбец в таблице и заполнили это, изменили первичный ключ на этот столбец и перекрепили все отношения с внешним ключом к новому ключу.

Очень грязно, но это сработало.

Ответ 3

Создайте новую таблицу с одинаковой структурой. Читайте от старого к новому (за исключением ПК). Затем удалите старый и переименуйте новый.