For det første antager jeg, at vi kan ignorere syntaksfejlene (f.eks. er der ingen END LOOP , dbms_output.put_line opkaldet mangler det første enkelt citat osv.)
Det afhænger af, om det er nødvendigt at rulle ændringer tilbage.
Generelt ville du ikke have midlertidige commits i en løkke. Det er generelt en dårlig arkitektur, både fordi det er meget dyrere i forhold til I/O og forløbet tid. Det gør det også meget sværere at skrive genstartbar kode. Hvad sker der f.eks. hvis din SELECT statement vælger 10 rækker, du udsteder (og begår) 5 opdateringer, og så mislykkes den 6. opdatering? Den eneste måde at kunne genstarte med den 6. række, efter at du har rettet undtagelsen, ville være at have en separat tabel, hvor du gemte (og opdaterer) din kodes fremskridt. Det skaber også problemer for enhver kode, der kalder denne blok, som derefter skal håndtere sagen om, at halvdelen af arbejdet blev udført (og begået), og den anden halvdel ikke var.
Generelt vil du kun placere transaktionskontroludsagn i de yderste blokke af din kode. Siden en COMMIT eller en ROLLBACK i en procedure forpligter eller ruller tilbage alt arbejde udført i sessionen, uanset om det blev udført af proceduren eller ej, vil du være meget forsigtig med at tilføje transaktionskontroludsagn. Du ønsker generelt at lade den, der ringer, tage beslutningen om, hvorvidt han skal forpligte sig eller rulle tilbage. Selvfølgelig går det kun så langt - til sidst vil du være i den yderste blok, der aldrig vil blive kaldt fra en anden rutine, og du skal have passende transaktionskontrol - men det er noget, du skal være meget forsigtig om, om du skriver kode, der kan genbruges.
I dette tilfælde, da du har midlertidige commits, er den eneste effekt af din ROLLBACK ville være, at hvis den første opdateringssætning mislykkedes, ville det arbejde, der var blevet udført i din session, før du kaldte denne blok, blive rullet tilbage. Den midlertidige commit ville begå disse tidligere ændringer, hvis den første opdateringserklæring var vellykket. Det er den slags bivirkning, som folk bekymrer sig om, når de taler om, hvorfor midlertidige forpligtelser og transaktionskontrol i genanvendelige blokke er problematiske.