Re: PL/SQL Block in Pro*C

From: Dogan Cibiceli <dcib_at_gwl.com>
Date: Fri, 18 Jun 1999 15:17:54 -0600
Message-ID: <376AB782.B195E207_at_gwl.com>


Hi,
  After some maling back & forth between Thomas, we agrred on those two things

  • Select into do cause an exception but I have used a min function in that select which I have neglected to mention. In that case, your pl/sql code will fall through to sql%found
  • Right about the work being undone :)

Dogan

PS. So Thomas is right on each account but this is just for informing the public :)

Thomas Kyte wrote:

> A copy of this was sent to Dogan Cibiceli <dcib_at_gwl.com>
> (if that email address didn't require changing)
> On Fri, 18 Jun 1999 11:23:48 -0600, you wrote:
>
> >Hi,
> > Rather pointless question but, suppose I have a PL/SQL block and I do
> >:) What happens if one of the statements generate a data_not_found
> >exception and I have no exception handler in my PL/SQL block in my Pro*C
> >module. How much will rollback be done.? Will there be rollback ?
> >The PL/SQL Block contains no procedures and no functions contains simple
> >two sql statements and one PL/SQL conditional. Here's how it looks in
> >big picture.
> >
>
> the work performed by the block will be undone. any work done prior to this
> block in your application will 'survive'.
>
> note that sql%found isn't valid for a select .. into ... from statement. The
> select into flings an exception when there is no data found. your if statement
> *never* gets executed if there is no data.
>
> >exec sql execute
> >declare
> > my stuff ;
> >begin
> > select from_tables
> > into my_stuff
> >
> > if (sql%found) then
> > if ( test dates )
> > update table
> > end if
> > end if
> >end
> >exec sql end-exec
> >
> >Thanks in adv.
> >
> >D
>
> --
> See http://govt.us.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'...
> Current article is "Fine Grained Access Control", added June 8'th
>
> Thomas Kyte tkyte_at_us.oracle.com
> Oracle Service Industries Reston, VA USA
>
> Opinions are mine and do not necessarily reflect those of Oracle Corporation
Received on Fri Jun 18 1999 - 23:17:54 CEST

Original text of this message