Re: DBMS_SQL.PARSE EXECUTES the cursor? (was Re: Developer question)
From: Adric Norris <landstander668_at_gmail.com>
Date: Mon, 5 Dec 2011 11:55:48 -0600
Message-ID: <CAJueESojqFeu=p0+U5vYZ4A9XDMsznjN62nD7GeY4pSuZvZuag_at_mail.gmail.com>
You're correct that it's expected
behaviour<http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_sql.htm#ARPLS68277>, but only because it's a DDL statement (drop table) rather than DML. DDL is run immediately when parsed.
On Mon, Dec 5, 2011 at 10:48, Taylor, Chris David < ChrisDavid.Taylor_at_ingrambarge.com> wrote:
Date: Mon, 5 Dec 2011 11:55:48 -0600
Message-ID: <CAJueESojqFeu=p0+U5vYZ4A9XDMsznjN62nD7GeY4pSuZvZuag_at_mail.gmail.com>
You're correct that it's expected
behaviour<http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_sql.htm#ARPLS68277>, but only because it's a DDL statement (drop table) rather than DML. DDL is run immediately when parsed.
On Mon, Dec 5, 2011 at 10:48, Taylor, Chris David < ChrisDavid.Taylor_at_ingrambarge.com> wrote:
> It appears that dbms_sql.parse executes the actual CURSOR in 10g.
> ...
> I'm guessing this is expected behavior even though DBMS_SQL has a separate
> EXECUTE procedure?
> ...
> SQL> declare
> 2 cursor_name INTEGER;
> 3 BEGIN
> 4 cursor_name := dbms_sql.open_cursor;
> 5 DBMS_SQL.PARSE(cursor_name, 'drop table test1', DBMS_SQL.NATIVE);
> 6 DBMS_SQL.CLOSE_CURSOR(cursor_name);
> 7 EXCEPTION
> 8 WHEN OTHERS THEN
> 9 DBMS_SQL.CLOSE_CURSOR(cursor_name);
> 10 raise;
> 11 END;
> 12 /
>
> PL/SQL procedure successfully completed.
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Dec 05 2011 - 11:55:48 CST