I experienced something I thought
unusual and wondered if it is due
to ORACLE's plan or Developer's
normal operation or a Developer
problem that might be something
you want to look in to.

I am operating in dual session mode.

I have a package that utilizes 3
GLOBAL TEMPORARY TABLES all created
with "ON COMMIT PRESERVE ROWS"
such as Oracle's example
===============================================
CREATE GLOBAL TEMPORARY TABLE my_temp_table (
column1 NUMBER,
column2 NUMBER
) ON COMMIT PRESERVE ROWS;
===============================================

The tables get "processed" by multiple
procedures always retaining their value.
Up until a point in one procedure where
all 3 tables seemed to get truncated
though only one is even mentioned in it
(acts like the session changed).

I was able to "fix" or "work around" by
making the following change.

Lines 3 thru 5 seem to be the problem.
In the origional procedure that failed
the variables are declared and assigned
an initial value.

I got it working by only declaring the
variables on 3 thru 5 and waiting till
after "begin" to assign the initial the
values on lines 14 thru 16.


failed
01 procedure group_Expires_Renewals is
02
03 this_ss number(10):=0;
04 this_date date:=to_date('1/1/1900','mm/dd/yyyy');
05 group_cnt number(10):=0;
06
07 cursor xxxx is
08 select * from CR_RETENTION_data_SS_INFO i1
09 order by
10 i1.ss_id
11 ,i1.edate;
12
13 begin
14 for y in xxxx loop
15


fixed
01 procedure group_Expires_Renewals is
02
03 this_ss number(10);
04 this_date date;
05 group_cnt number(10);
06
07 cursor xxxx is
08 select * from CR_RETENTION_data_SS_INFO i1
09 order by
10 i1.ss_id
11 ,i1.edate;
12
13 begin
14 this_ss:=0;
15 this_date:=to_date('1/1/1900','mm/dd/yyyy');
16 group_cnt:=0;
17
18
19 for y in xxxx loop
20

Thanks

Dave