Это по-прежнему очень распространенная проблема среди многих разработчиков и приложений независимо от размера.
К сожалению, приведенные выше предложения не исправляют все сценарии, например, виртуальный хостинг, вы не можете полагаться на свой хост при установке параметра запуска -t272.
Кроме того, если у вас есть существующие таблицы, которые используют эти столбцы идентификаторов для первичных ключей, это ОГРОМНОЕ усилие, чтобы удалить эти столбцы и воссоздать новые, чтобы использовать обходной путь последовательности BS. Обходной путь Sequence хорош только в том случае, если вы создаете новые таблицы с нуля в SQL 2012+.
Суть в том, что если вы используете Sql Server 2008R2, оставайтесь на нем. Серьезно, оставайся на этом. Пока Microsoft не признает, что они представили ОГРОМНУЮ ошибку, которая все еще существует даже в Sql Server 2016, мы не должны обновляться до тех пор, пока они не станут ее владельцем и не ИСПРАВЛЯЮТ ИТ.
Microsoft сразу же внесла критическое изменение, то есть они сломали рабочий API, который больше не работает так, как задумано, из-за того, что их система забывает их текущую идентификацию при перезапуске. Кэширование или отсутствие кеша - это неприемлемо, и разработчик Microsoft по имени Брайан должен владеть им, вместо того, чтобы говорить миру, что это «по замыслу» и «функция». Конечно, кэширование - это функция, но потеря информации о том, какой должна быть следующая личность, НЕ ЯВЛЯЕТСЯ ФУНКЦИЕЙ. Это чертова ОШИБКА !!!
Я поделюсь обходным путем, который я использовал, потому что мои БД находятся на серверах общего хостинга, а также я не удаляю и не воссоздаю свои столбцы первичного ключа, что было бы огромным PITA.
Вместо этого это мой постыдный хакер (но не такой постыдный, как эта ошибка POS, которую представила Microsoft).
Hack / Fix:
Перед вашими командами вставки просто повторно заполняйте вашу личность перед каждой вставкой. Это исправление рекомендуется только в том случае, если у вас нет административного контроля над экземпляром Sql Server, в противном случае я предлагаю выполнить повторное заполнение при перезапуске сервера.
declare @newId int -- where int is the datatype of your PKey or Id column
select @newId = max(YourBuggedIdColumn) from YOUR_TABLE_NAME
DBCC CheckIdent('YOUR_TABLE_NAME', RESEED, @newId)
Просто эти 3 строки непосредственно перед вставкой, и все готово. Это действительно не сильно повлияет на производительность, т.е. будет незаметно.
Удачи.
order by ReceiptNo
в свой запрос, действительно ли этих записей нет? Вы уверены, что при вставке записей ошибок нет? Если запись пытается вставить, но не удается, идентификатор будет увеличиваться, то же самое при удалении записей. Если записи удаленыReceiptNo
, сброс не выполняется. Можете ли вы разместить таблицу создания дляFee
таблицы?