Błąd CHECK constraint

Błąd CHECK constraint sygnalizuje próbę wstawienia wartości naruszającej zdefiniowany warunek walidacji danych kolumny.

Rola warunku CHECK w walidacji danych

Warunek CHECK jest mechanizmem walidacji zapisanym w definicji tabeli relacyjnej. Określa wyrażenie logiczne, które musi być spełnione przez każdą wartość zapisywaną w objętej nim kolumnie albo przez zestaw kolumn. Jeżeli aplikacja próbuje wstawić lub zmienić wiersz tak, aby wyrażenie przyjęło wartość fałszu, silnik bazy danych odrzuca operację i zgłasza błąd naruszenia CHECK constraint. Nie jest to awaria sprzętu, lecz informacja, że przesłane dane nie spełniają reguły ustalonej dla tabeli.

Przykładowy warunek może wymagać, aby liczba sztuk była większa lub równa zero, status należał do określonego zbioru wartości albo data zakończenia nie była wcześniejsza od daty rozpoczęcia. CHECK constraint różni się od ograniczenia NOT NULL, ponieważ nie tylko sprawdza obecność wartości, lecz ocenia zdefiniowane wyrażenie. Różni się także od klucza obcego, który kontroluje powiązanie z rekordem w innej tabeli. Każdy z tych mechanizmów pilnuje innej właściwości spójności danych.

Jak powstaje naruszenie CHECK constraint

Błąd pojawia się najczęściej wtedy, gdy formularz, import danych albo program przekaże wartość spoza dozwolonego zakresu. Jeśli dla kolumny określono warunek, że cena musi być większa od zera, próba zapisania zera lub liczby ujemnej zostanie odrzucona. Podobnie zadziała reguła ograniczająca kolumnę statusu do wartości takich jak „nowy”, „w toku” i „zamknięty”, gdy aplikacja prześle nieprzewidziany tekst, literówkę albo wartość pochodzącą ze starszej wersji programu.

Problemy mogą również wystąpić podczas aktualizacji istniejących rekordów. Operacja zmieniająca jedną kolumnę może naruszyć warunek zależny od kilku pól, nawet jeśli nowa wartość sama w sobie wygląda poprawnie. Przykładem jest rekord, w którym data zakończenia musi być późniejsza lub równa dacie rozpoczęcia. Zmiana daty rozpoczęcia bez równoczesnego dostosowania daty zakończenia może spowodować odrzucenie całej instrukcji. Naruszenie może pojawić się także przy imporcie, migracji lub odtwarzaniu danych, gdy źródłowy system dopuszczał wartości, których docelowa tabela już nie akceptuje.

Odczyt komunikatu i ustalenie właściwej przyczyny

Samo określenie „CHECK constraint violation” nie wskazuje jeszcze, która wartość jest błędna. Do prawidłowej diagnozy potrzebne są nazwa tabeli, nazwa ograniczenia, wykonywana operacja oraz wartości przekazane przez aplikację. Nazwa constraintu często opisuje regułę, na przykład zakres liczbowy albo dozwolony status, ale nie zawsze jest wystarczająco jednoznaczna. Należy porównać komunikat z aktualną definicją tabeli, ponieważ reguła mogła zostać zmieniona po wdrożeniu aplikacji.

W praktyce warto sprawdzić, czy aplikacja i baza danych używają tego samego modelu wartości. Częstym źródłem błędu jest rozbieżność między pustym tekstem, wartością NULL i wartością domyślną. Nie są one równoważne: pusty tekst jest konkretną wartością tekstową, natomiast NULL oznacza brak wartości. Znaczenie NULL w wyrażeniu CHECK zależy od logiki trójwartościowej używanej przez relacyjne bazy danych, dlatego warunek uznawany za prawdziwy dla zwykłych wartości może wymagać osobnego ograniczenia NOT NULL. Trzeba też zweryfikować typy danych, konwersje jednostek, wartości domyślne i kolejność wykonywania walidacji po stronie programu.

Naprawa danych i przywrócenie zgodności

Usunięcie błędu polega na doprowadzeniu danych i reguły walidacyjnej do zgodności, a nie na mechanicznym wyłączeniu ograniczenia. Najpierw należy ustalić, czy niepoprawna jest pojedyncza wartość, mapowanie pól w aplikacji, dane importowane z zewnętrznego pliku czy sama definicja warunku. Jeżeli wartość jest błędna, poprawia się źródło danych albo przygotowuje kontrolowaną korektę rekordu. Jeżeli reguła została zaprojektowana niezgodnie z rzeczywistym procesem, jej zmiana wymaga sprawdzenia istniejących wierszy oraz wszystkich operacji, które korzystają z danej tabeli.

Przy diagnostyce laptopa lub komputera PC można przeanalizować komunikat aplikacji, konfigurację programu, logi oraz sposób połączenia z bazą, o ile problem objawia się na używanym stanowisku. Warto zachować kopię danych i najpierw przetestować korektę na środowisku przeznaczonym do sprawdzeń. Należy również wykluczyć błędy połączenia, nieaktualny klient, niezgodny formularz lub częściowo wdrożoną wersję programu, ponieważ sama baza może działać prawidłowo, odrzucając jedynie dane niespełniające zapisanej reguły.