Tout d'abord, je suppose que nous pouvons ignorer les erreurs de syntaxe (par exemple, il n'y a pas de END LOOP , le dbms_output.put_line call manque le premier guillemet simple, etc.)
Quant à savoir s'il est nécessaire d'annuler les modifications, cela dépend.
En général, vous n'auriez pas de commits intermédiaires dans une boucle. C'est généralement une mauvaise architecture à la fois parce qu'elle est beaucoup plus coûteuse en termes d'E/S et de temps écoulé. Cela rend également beaucoup plus difficile l'écriture de code redémarrable. Que se passe-t-il, par exemple, si votre SELECT sélectionne 10 lignes, vous émettez (et validez) 5 mises à jour, puis la 6e mise à jour échoue ? La seule façon de pouvoir redémarrer avec la 6ème ligne après avoir corrigé l'exception serait d'avoir une table séparée dans laquelle vous stockez (et mettez à jour) la progression de votre code. Cela crée également des problèmes pour tout code qui appelle ce bloc qui doit ensuite gérer le cas où la moitié du travail a été effectuée (et validée) et l'autre moitié ne l'a pas été.
En général, vous ne placeriez que des instructions de contrôle de transaction dans les blocs les plus externes de votre code. Depuis un COMMIT ou un ROLLBACK dans une procédure valide ou annule tout travail effectué dans la session, qu'il ait été effectué ou non par la procédure, vous devez être très prudent lors de l'ajout d'instructions de contrôle de transaction. Vous souhaitez généralement laisser l'appelant décider s'il doit valider ou annuler. Bien sûr, cela ne va que si loin - éventuellement, vous serez dans le bloc le plus externe qui ne sera jamais appelé par une autre routine et vous devez avoir un contrôle de transaction approprié - mais c'est quelque chose d'être très prudent savoir si vous écrivez du code qui pourrait être réutilisé.
Dans ce cas, puisque vous avez des commits intermédiaires, le seul effet de votre ROLLBACK serait que si la première instruction de mise à jour échouait, le travail qui avait été effectué dans votre session avant d'appeler ce bloc serait annulé. La validation intermédiaire validerait ces modifications précédentes si la première instruction de mise à jour réussissait. C'est le genre d'effet secondaire dont les gens s'inquiètent lorsqu'ils expliquent pourquoi les commits intermédiaires et le contrôle des transactions dans les blocs réutilisables sont problématiques.
