05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

260<br />

CHAPTER 8 ■ TRANSACTIONS<br />

CNT<br />

----------<br />

0<br />

So, we have a procedure we know will fail. The second INSERT will always fail in this case.<br />

Let’s see what happens if we run that stored procedure:<br />

ops$tkyte@ORA10G> begin<br />

2 p;<br />

3 end;<br />

4 /<br />

I fired <strong>and</strong> updated 1 rows<br />

I fired <strong>and</strong> updated 1 rows<br />

begin<br />

*<br />

ERROR at line 1:<br />

ORA-02290: check constraint (OPS$TKYTE.SYS_C009598) violated<br />

ORA-06512: at "OPS$TKYTE.P", line 5<br />

ORA-06512: at line 2<br />

ops$tkyte@ORA10G> select * from t;<br />

no rows selected<br />

ops$tkyte@ORA10G> select * from t2;<br />

CNT<br />

----------<br />

0<br />

As you can see, <strong>Oracle</strong> treated the stored procedure call as an atomic statement. The<br />

client submitted a block of code, BEGIN P; END;, <strong>and</strong> <strong>Oracle</strong> wrapped a SAVEPOINT around it.<br />

Since P failed, <strong>Oracle</strong> restored the database back to the point right before it was called. Now,<br />

if we submit a slightly different block, we will get entirely different results:<br />

ops$tkyte@ORA10G> begin<br />

2 p;<br />

3 exception<br />

4 when others then null;<br />

5 end;<br />

6 /<br />

I fired <strong>and</strong> updated 1 rows<br />

I fired <strong>and</strong> updated 1 rows<br />

PL/SQL procedure successfully completed.<br />

ops$tkyte@ORA10G> select * from t;

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!