Polecenie DBCC CHECKIDENT
zarządzania służy do resetowania licznika tożsamości. Składnia polecenia jest następująca:
DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]
Przykład:
DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO
Nie był obsługiwany w poprzednich wersjach bazy danych SQL Azure, ale jest teraz obsługiwany.
Należy pamiętać, że new_reseed_value
argument jest różny w różnych wersjach SQL Server zgodnie z dokumentacją :
Jeśli wiersze są obecne w tabeli, następny wiersz jest wstawiany z wartością new_reseed_value . W wersji SQL Server 2008 R2 i wcześniejszych, następny wstawiony wiersz używa nowej_reseed_value + bieżąca wartość przyrostu.
Jednak uważam tę informację za mylącą (właściwie po prostu błędną), ponieważ zaobserwowane zachowanie wskazuje, że przynajmniej SQL Server 2012 nadal używa nowej_reseed_value + bieżącej logiki wartości przyrostowej. Microsoft zaprzecza nawet własnej Example C
znalezionej na tej samej stronie:
C. Zmuszenie bieżącej wartości tożsamości do nowej wartości
Poniższy przykład wymusza bieżącą wartość tożsamości w kolumnie AddressTypeID w tabeli AddressType na wartość 10. Ponieważ tabela zawiera istniejące wiersze, następny wstawiony wiersz użyje 11 jako wartości, czyli nowej bieżącej wartości przyrostu zdefiniowanej dla wartość kolumny plus 1.
USE AdventureWorks2012;
GO
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO
Mimo to wszystko pozostawia opcję odmiennego zachowania w nowszych wersjach SQL Server. Myślę, że jedynym sposobem, aby się upewnić, dopóki Microsoft nie wyjaśni rzeczy we własnej dokumentacji, jest wykonanie rzeczywistych testów przed użyciem.