Błąd w logice procedury

Błąd w logice procedury sygnalizuje niepoprawność sekwencji operacji zaimplementowanej wewnątrz procedury składowanej.

Na czym polega błąd w logice procedury składowanej

Błąd w logice procedury składowanej występuje wtedy, gdy procedura wykonuje operacje zgodnie ze składnią danego systemu bazodanowego, lecz kolejność albo warunki tych operacji prowadzą do nieprawidłowego wyniku. Taki problem różni się od błędu składniowego, ponieważ kod może zostać zapisany, skompilowany i uruchomiony bez komunikatu o awarii. Nie oznacza to jednak, że procedura realizuje wymagany proces. Przykładem jest zapisanie rekordu przed sprawdzeniem warunku, aktualizacja niewłaściwych wierszy albo obliczenie wartości na podstawie danych pobranych przed zakończeniem wcześniejszej operacji.

Procedura składowana jest zbiorem instrukcji przechowywanym w bazie danych i wykonywanym jako określona całość. Może przyjmować parametry wejściowe, odczytywać dane, modyfikować rekordy, wywoływać inne procedury oraz zwracać wynik lub kod statusu. Błąd logiczny pojawia się, gdy zależności między tymi czynnościami nie odpowiadają regułom aplikacji. Sama obecność poprawnych poleceń nie wystarcza do potwierdzenia poprawności. Trzeba jeszcze sprawdzić, czy dla różnych danych wejściowych procedura podejmuje właściwą decyzję, zachowuje spójność danych i zwraca wynik w oczekiwanym momencie.

Sekwencja operacji, warunki i zależności między danymi

Jednym z częstych przypadków jest pominięcie zależności czasowej między instrukcjami. Jeżeli procedura najpierw pobiera stan magazynowy, a dopiero potem rejestruje równoległą zmianę, wynik może być oparty na nieaktualnej wartości. Podobny problem występuje podczas obsługi zamówienia: procedura może oznaczyć zamówienie jako zrealizowane, zanim sprawdzi dostępność wszystkich pozycji. Każda instrukcja może działać poprawnie osobno, ale ich kolejność tworzy błędny przebieg całego procesu.

Analizy wymagają również instrukcje warunkowe. Warunek może obejmować zbyt wąski zakres wartości, pomijać wartość pustą albo traktować zero jako brak danych, mimo że w danym procesie zero jest prawidłową wartością. Błąd może wynikać także z niepełnego zestawu gałęzi decyzyjnych. Jeśli procedura obsługuje przypadek pozytywny i negatywny, ale nie przewiduje sytuacji, w której zapytanie nie zwróci żadnego rekordu, dalsze instrukcje mogą wykorzystać nieustaloną albo nieaktualną wartość. Weryfikacja powinna obejmować dane typowe, graniczne, niekompletne oraz takie, które prowadzą do każdego możliwego wariantu decyzji.

Jak rozpoznać niepoprawny przebieg procedury

Rozpoznanie błędu logicznego wymaga porównania oczekiwanego przebiegu z rzeczywistymi zmianami w bazie. Przydatne jest opisanie procedury jako sekwencji kroków: odczyt parametrów, wyszukanie rekordów, sprawdzenie warunków, modyfikacja danych, zapis wyniku i obsługa sytuacji wyjątkowych. Następnie każdy krok porównuje się z wymaganiem, które powinien realizować. Warto sprawdzić, czy filtr identyfikuje właściwy rekord, czy połączenie tabel nie zwielokrotnia wyników oraz czy aktualizacja nie obejmuje większej liczby wierszy niż zamierzona.

Istotne są także wartości zwracane przez procedurę. Kod wywołujący może uznać operację za udaną na podstawie samego zakończenia wykonania, podczas gdy procedura nie zmieniła żadnego rekordu albo zmieniła rekord niewłaściwy. Należy więc kontrolować liczbę przetworzonych wierszy, wartości parametrów wyjściowych, komunikaty statusu oraz efekt końcowy widoczny po ponownym odczycie danych. Przydatne jest uruchamianie procedury na kontrolnym zestawie danych i porównywanie stanu przed oraz po wykonaniu. Jeżeli wynik zależy od kilku instrukcji modyfikujących dane, trzeba również sprawdzić, czy częściowo wykonany proces nie pozostawia niespójnego stanu po przerwaniu działania.

Porządkowanie procedury i potwierdzenie poprawki

Usunięcie błędu powinno rozpocząć się od jednoznacznego opisania reguły biznesowej, którą procedura ma realizować. Dopiero potem można zmienić warunek, kolejność poleceń albo sposób przekazywania wartości między etapami. W kodzie warto rozdzielić pobieranie danych od ich modyfikacji, nazwać parametry i zmienne zgodnie z ich znaczeniem oraz ograniczyć zakres każdej operacji do rekordów wskazanych przez parametry. Takie uporządkowanie ułatwia sprawdzenie, czy procedura wykonuje dokładnie te czynności, które wynikają z jej przeznaczenia.

Po wprowadzeniu korekty należy powtórzyć testy dla przebiegu prawidłowego, braku danych, wartości granicznych, wielokrotnego wywołania i przerwania procesu w newralgicznym momencie. Trzeba też sprawdzić współdziałanie procedury z aplikacją, ponieważ poprawny wynik w bezpośrednim wywołaniu może zostać błędnie zinterpretowany przez kod klienta. Jeżeli problem dotyczy procedury używanej przez system działający na komputerze, analiza powinna objąć logi wywołań, przekazywane parametry, czas wykonania oraz stan rekordów przed i po operacji. Dopiero zgodność tych elementów potwierdza, że poprawka usunęła przyczynę, a nie tylko pojedynczy objaw.