Matt
First, did we ever determine if you are related to the "Dwead Piwate Woberts?"
Secondly, the "/" following a PL/SQL block marks the physical end of the PL/SQL block and directs SQL*Plus to pass the code to the PL/SQL interpreter. It does not imply a "COMMIT". If your group are in the habit if issuing a "COMMIT" following a PL/SQL block, then that should be fine. Just understand these concepts:
1) "COMMIT" has an effect only if you have executed INSERT, UPDATE, DELETE, or a cursor in your PL/SQL block.
2) Syntactically, you may execute a COMMIT inside your PL/SQL or outside your PL/SQL block.
3) If you do not explicitly execute a COMMIT, then Oracle deals with any previously unCOMMITted changes as it would if those changes occurred as standard SQL: i.e., they remain uncommitted until you either:
a) issue an orderly disconnect (e.g. "exit", "quit") from SQL*Plus at which time Oracle automatically COMMITs your updates
b) suffer an abnormal end to your session (e.g., due to power failure) at which time Oracle automatically executes a ROLLBACK on your updates
c) issue an explicit COMMIT or ROLLBACK at which time Oracle executes what you requested.
And, of course, every DBA should be aware that
"COMMIT" happens (
![[wink] [wink] [wink]](/data/assets/smilies/wink.gif)
)...just a philosophical observation and a great line for a bumper sticker.
So, when your team, as a matter of habit, course, or standard, issues a COMMIT following the execution of a PL/SQL block, it is a
choice, not a
requirement.
![[santa] [santa] [santa]](/data/assets/smilies/santa.gif)
Mufasa
(aka Dave of Sandy, Utah, USA)
@ 16:51 (29Nov04) UTC (aka "GMT" and "Zulu"),
@ 09:51 (29Nov04) Mountain Time