Home » SQL & PL/SQL » SQL & PL/SQL » Problem with implicit cursors when used with Autonomous Transactions
Problem with implicit cursors when used with Autonomous Transactions [message #7851] Sat, 12 July 2003 06:47 Go to next message
Parag
Messages: 10
Registered: July 2002
Junior Member
To PL/SQL experts,

I am using two proc.s, one updates a table called p_update_tbl and another which writes debug msg to a debug table p_add_debug_msg. The second proc. is an autonomous transaction. I call these procedures for some 2000 records in a loop with p_update_tbl called first and the p_add_debug_msg called second. Now after p_add_debug_msg is over I am accessing SQL%ROWCOUNT to get the no. of records updated by p_update_tbl. This one works sometimes, and sometimes it doesn't!

I want to know if the implicit cursor is seperate for EACH transaction or is saved in some common area for all the transactions and hence the implicit cursor (SQL) is getting re-used sometimes for the autonomous transaction and hence I loose the SQL%ROWCOUNT value for the update statement.

According to my belief the two transactions should have seperate implicit cursors (SQL) which will serve to these transactions ONLY. And will be over-written with new values as and when any implicit cursor command is written in the same transaction and not in any other transaction. Untill I run another implicit cursor command in the same transaction, I should be able to retrieve all the attributes of the cursor, exceptions to this rule being commit & rollback.

Help me urgently as because of this I may be needed to change the code.

Thanks,
Parag.
Re: Problem with implicit cursors when used with Autonomous Transactions [message #7875 is a reply to message #7851] Mon, 14 July 2003 13:33 Go to previous message
Todd Barry
Messages: 4819
Registered: August 2001
Senior Member
You will want to check the SQL%ROWCOUNT after the update but before the call to the autonomous transaction (AT). The commit in the AT will reset the SQL%ROWCOUNT value to 0, so it is not of any use to check this value after the AT.

It is really not a case of "sometimes it works/sometimes it doesn't" - you are just interpreting a value of 0 as a failed update when in fact it is always returning 0.

sql>create table t (c int);
 
Table created.
 
sql>create table log (c int);
 
Table created.
 
sql>insert into t select rownum from all_objects where rownum <= 5;
 
5 rows created.
 
sql>create or replace package pkg_test
  2  is
  3    procedure a(p_id in t.c%type);
  4    procedure b(p_numrows in pls_integer);
  5  end;
  6  /
 
Package created.
 
sql>create or replace package body pkg_test
  2  is
  3    procedure a(p_id in t.c%type)
  4    is
  5    begin
  6      update t
  7         set c = c
  8       where c = p_id;
  9       
 10      dbms_output.put_line( 'Before b: ' || sql%rowcount );
 11  
 12      b(p_id);
 13      
 14      dbms_output.put_line( 'After b, before commit: ' || sql%rowcount );
 15      commit;
 16      dbms_output.put_line( 'After b, after commit: ' || sql%rowcount );
 17    end;
 18    
 19    procedure b(p_numrows in pls_integer)
 20    is
 21      pragma autonomous_transaction;
 22    begin
 23      insert into log
 24        select object_id
 25          from all_objects
 26         where rownum <= p_numrows;
 27  
 28      dbms_output.put_line( 'In b, before commit: ' || sql%rowcount );   
 29      commit;
 30      dbms_output.put_line( 'In b, after commit: ' || sql%rowcount );
 31    end;
 32  end;
 33  /
 
Package body created.
 
sql>exec pkg_test.a(2)
Before b: 1
In b, before commit: 2
In b, after commit: <b>0</b>
After b, before commit: <b>0</b>
After b, after commit: 0
Previous Topic: FRM-40508/ORA-00001
Next Topic: sequence order of events
Goto Forum:
  


Current Time: Fri Apr 19 11:28:54 CDT 2024