Innanzitutto, presumo che possiamo ignorare gli errori di sintassi (ad esempio, non esiste END LOOP , il dbms_output.put_line nella chiamata manca la prima virgoletta singola, ecc.)
Dipende se è necessario annullare le modifiche.
In generale, non avresti commit provvisori in un ciclo. Questa è generalmente un'architettura scadente sia perché è molto più costosa in termini di I/O e tempo trascorso. Inoltre, rende molto più difficile scrivere codice riavviabile. Cosa succede, ad esempio, se il tuo SELECT l'istruzione seleziona 10 righe, emetti (e commetti) 5 aggiornamenti e quindi il sesto aggiornamento non riesce? L'unico modo per poter riavviare con la 6a riga dopo aver corretto l'eccezione sarebbe avere una tabella separata in cui hai archiviato (e aggiornato) l'avanzamento del codice. Crea anche problemi per qualsiasi codice che chiama questo blocco che deve quindi gestire il caso in cui metà del lavoro è stato eseguito (e eseguito il commit) e l'altra metà no.
In generale, inseriresti solo le istruzioni di controllo delle transazioni nei blocchi più esterni del tuo codice. Dato che un COMMIT o un ROLLBACK in una procedura esegue il commit o il rollback di qualsiasi lavoro svolto nella sessione, indipendentemente dal fatto che sia stato eseguito o meno dalla procedura, si consiglia di essere molto cauti nell'aggiungere istruzioni di controllo della transazione. In genere si desidera consentire al chiamante di decidere se eseguire il commit o il rollback. Ovviamente, questo va solo così lontano-- alla fine, ti troverai nel blocco più esterno che non verrà mai chiamato da qualche altra routine e devi avere un controllo delle transazioni appropriato-- ma è qualcosa di cui stare molto attenti se stai scrivendo codice che potrebbe essere riutilizzato.
In questo caso, dato che hai dei commit provvisori, l'unico effetto del tuo ROLLBACK sarebbe che se la prima istruzione di aggiornamento falliva, il lavoro che era stato fatto nella tua sessione prima di chiamare questo blocco sarebbe stato annullato. Il commit provvisorio commetterebbe quelle modifiche precedenti se la prima istruzione di aggiornamento avesse esito positivo. Questo è il tipo di effetto collaterale di cui le persone si preoccupano quando parlano del motivo per cui i commit temporanei e il controllo delle transazioni nei blocchi riutilizzabili sono problematici.
