Po pierwsze, zakładam, że możemy zignorować błędy składniowe (na przykład nie ma END LOOP , dbms_output.put_line w połączeniu brakuje pierwszego pojedynczego cudzysłowu itp.)
To, czy konieczne jest cofnięcie zmian, zależy od tego.
Ogólnie rzecz biorąc, nie będziesz miał tymczasowych zmian w pętli. Jest to generalnie słaba architektura, ponieważ jest znacznie bardziej kosztowna pod względem we/wy i czasu, który upłynął. To również znacznie utrudnia pisanie kodu, który można ponownie uruchomić. Co się stanie, na przykład, jeśli Twój SELECT instrukcja wybiera 10 wierszy, wydajesz (i zatwierdzasz) 5 aktualizacji, a następnie 6. aktualizacja kończy się niepowodzeniem? Jedynym sposobem na ponowne uruchomienie z szóstym wierszem po naprawieniu wyjątku byłoby posiadanie oddzielnej tabeli, w której zapisałeś (i aktualizujesz) postęp kodu. Stwarza to również problemy dla każdego kodu, który wywołuje ten blok, który musi następnie obsłużyć przypadek, w którym połowa pracy została wykonana (i zatwierdzona), a druga połowa nie.
Ogólnie rzecz biorąc, deklaracje kontroli transakcji umieszczasz tylko w najbardziej zewnętrznych blokach kodu. Od COMMIT lub ROLLBACK w procedurze zatwierdza lub wycofuje wszelką pracę wykonaną w sesji, niezależnie od tego, czy została wykonana przez procedurę, czy nie, chcesz być bardzo ostrożny przy dodawaniu instrukcji kontroli transakcji. Generalnie chcesz, aby dzwoniący podjął decyzję o zatwierdzeniu lub wycofaniu. Oczywiście to tylko tak daleko — w końcu znajdziesz się w najbardziej zewnętrznym bloku, który nigdy nie zostanie wywołany z innej procedury i musisz mieć odpowiednią kontrolę transakcji — ale należy być bardzo ostrożnym o tym, czy piszesz kod, który może zostać ponownie wykorzystany.
W tym przypadku, ponieważ masz tymczasowe zatwierdzenia, jedyny efekt twojego ROLLBACK byłoby to, że jeśli pierwsza instrukcja aktualizacji nie powiedzie się, praca wykonana w sesji przed wywołaniem tego bloku zostanie wycofana. Zatwierdzenie tymczasowe zatwierdzi poprzednie zmiany, jeśli pierwsza instrukcja aktualizacji zakończy się pomyślnie. Jest to rodzaj efektu ubocznego, o który ludzie martwią się, gdy mówią o tym, dlaczego tymczasowe zatwierdzenia i kontrola transakcji w blokach wielokrotnego użytku są problematyczne.
