Błąd tożsamości (IDENTITY) sygnalizuje problem z automatycznym generowaniem kolejnych wartości klucza w kolumnie tego typu.
IDENTITY jako właściwość kolumny w SQL Server
W Microsoft SQL Server właściwość IDENTITY przypisana do kolumny tabeli służy do automatycznego generowania kolejnych wartości liczbowych podczas dodawania wierszy. Definiuje się ją przy tworzeniu kolumny, podając wartość początkową, czyli seed, oraz przyrost, czyli increment. Przykładowo zapis IDENTITY(1,1) oznacza rozpoczęcie numeracji od 1 i zwiększanie wartości o 1. Mechanizm ten jest często używany przy kluczach głównych, ale sama właściwość IDENTITY nie ustanawia jeszcze unikalności ani nie tworzy automatycznie klucza głównego.
Określenie „błąd tożsamości” nie oznacza jednego, uniwersalnego komunikatu SQL Server. Najczęściej opisuje problem związany z wartością generowaną przez kolumnę IDENTITY, nieprawidłowym zakresem numeracji albo próbą ręcznego przypisania wartości. Przy analizie trzeba ustalić nazwę tabeli i kolumny, typ danych, aktualny stan licznika oraz dokładny tekst błędu. Bez tych informacji można pomylić problem z błędem ograniczenia PRIMARY KEY, przepełnieniem typu liczbowego albo konfliktem wynikającym z konfiguracji IDENTITY_INSERT.
Najczęstsze przyczyny nieprawidłowych wartości
Jedną z typowych przyczyn jest jawne podanie wartości do kolumny tożsamości podczas instrukcji INSERT. Domyślnie SQL Server oczekuje, że wartość tej kolumny zostanie wygenerowana automatycznie. Próba zapisania własnego numeru do kolumny IDENTITY powoduje błąd, chyba że dla konkretnej tabeli włączono SET IDENTITY_INSERT nazwa_tabeli ON. Ustawienie to dotyczy jednej tabeli w danej sesji i wymaga jawnego określenia kolumn w instrukcji INSERT. Po zakończeniu kontrolowanego importu powinno zostać wyłączone.
Wartości tożsamości mogą zawierać luki i nie jest to samo w sobie oznaką uszkodzenia danych. Numer może zostać przydzielony przed zatwierdzeniem transakcji, a następnie pozostać niewykorzystany po wycofaniu operacji. Luki mogą także powstać po usunięciu wierszy. Mechanizm IDENTITY nie obiecuje ciągłej numeracji bez przerw; jego zadaniem jest generowanie wartości zgodnie z ustawionym przyrostem. Jeżeli aplikacja wymaga kolejnych numerów bez luk, identyfikator techniczny nie powinien być traktowany jako numer dokumentu, kolejność zdarzeń ani dowód liczby zapisanych rekordów.
Sprawdzanie licznika i zakresu numeracji
Stan licznika można skontrolować poleceniem DBCC CHECKIDENT. Instrukcja DBCC CHECKIDENT ('dbo.Tabela', NORESEED) odczytuje bieżącą wartość tożsamości oraz maksymalną wartość znajdującą się w kolumnie. Różnica między nimi może wskazywać, że licznik nie odpowiada zawartości tabeli, ale interpretacja zależy od kierunku przyrostu, usuniętych rekordów i sposobu wcześniejszego ładowania danych. Sam odczyt nie naprawia numeracji i nie zmienia danych.
W uzasadnionych przypadkach administrator może skorygować licznik przez DBCC CHECKIDENT z opcją RESEED, jednak takie działanie wymaga wcześniejszego sprawdzenia istniejących wartości. Ustawienie zbyt niskiej wartości może doprowadzić do wygenerowania numeru już obecnego w tabeli, a w konsekwencji do naruszenia unikalności klucza. Ustawienie zbyt wysokiej wartości tworzy lukę, która zwykle nie jest błędem technicznym, ale może zaburzyć oczekiwania aplikacji. Należy też sprawdzić typ kolumny, ponieważ licznik nie może przekroczyć jego zakresu, na przykład zakresu int albo bigint.
Diagnostyka problemu w działającej bazie
Rzetelna diagnostyka powinna rozpocząć się od ustalenia, czy błąd występuje podczas INSERT, importu danych, odtwarzania kopii, synchronizacji czy zwykłej pracy aplikacji. Następnie sprawdza się definicję tabeli, właściwość IDENTITY, ograniczenia unikalności, triggery oraz kod odpowiedzialny za zapis. Ważne jest również rozróżnienie między błędem generowania identyfikatora a błędem referencji: wartość wygenerowana poprawnie może nadal prowadzić do niepowodzenia, jeżeli inne kolumny naruszają relację klucza obcego lub ograniczenie CHECK.
Przy naprawie nie należy automatycznie usuwać rekordów ani zmieniać licznika. Najpierw trzeba zabezpieczyć kopię danych, odtworzyć scenariusz na kontrolowanym środowisku i sprawdzić, czy aplikacja nie wysyła własnej wartości do kolumny tożsamości. W przypadku przepełnienia konieczna może być analiza modelu danych i planowana zmiana typu, natomiast przy błędnym imporcie właściwsze bywa poprawienie mapowania kolumn oraz ponowne wykonanie transakcji. Diagnostyka problemów z mechanizmem IDENTITY powinna uwzględniać zarówno definicję tabeli SQL Server, jak i rzeczywisty przepływ danych między aplikacją a bazą.
