Re: Data changing when exporting and importing a table

From: Papa Piquillo <oraclejva_at_yahoo.es>
Date: 5 Jun 2006 00:44:16 -0700
Message-ID: <1149493456.041178.143460@g10g2000cwb.googlegroups.com>

Thanks for the update. The table doesn't exist in sid2. Looking in metalink i have found that the problem seems to be a bug for 8i/9i.
The bug is very easy work-aroundable. The most easy way to avoid it is to use direct=y when exporting.
Anyway, it is worrying to find this issues (i do exports every day) and it should be fixed in a later release like 9.2.

Steve Howard ha escrito:

> Papa Piquillo wrote:
> > Hello Group:
> > Im using Oracle 9206 under hp-ux pa-risc 11.11
> > I have done the following:
> > exp user/pass_at_sid1 file=punica.dmp tables=tmp_paga_unica
> > imp user/pass_at_sid2 file=punica.dmp fromuser=user touser=user
> > No warnings, no errors. Same NLS character set.
> >
> > The table tmp_paga_unica is like:
> > Name Null? Type
> > ----------------------------------------- --------
> > ----------------------------
> > COD_PERSONA NUMBER(8)
> > DI_VALOR NUMBER
> > SQL> select count(*)
> > 2 from tmp_paga_unica;
> >
> > COUNT(*)
> > ----------
> > 329
> > (not very big :)
> >
> > And after importing the value of di_valor for some values of
> > cod_persona changes.
> > (sid1)
> > select *
> > from tmp_paga_unica
> > where cod_persona = 964
> > COD_PERSONA DI_VALOR
> > ----------- ----------
> > 964 373.8
> >
> > (sid2)
> > SQL> r
> > 1 select *
> > 2 from tmp_paga_unica
> > 3* where cod_persona = 964
> >
> > COD_PERSONA DI_VALOR
> > ----------- ----------
> > 964 123.55
> >
> >
> > I have reproduced the issue on oracle 8.1.7.4
> > Has anybody seen anything like this??
> > Thanks.

>

> I have never seen this. The only thing I can think of is if the table
> already exists in sid2, and there is a trigger on it that manipulates
> the value of :new.di_valor. However, since your command line does not
> include an ignore=y parameter, the table would be newly created in
> sid2.

>

> You may want to put a 10046 trace on any sessions that use imp as the
> program in v$session, perhaps via a logon trigger in sid2. You could
> then see exactly what it was doing on the insert during import.
>
> Regards,
>
> Steve
Received on Mon Jun 05 2006 - 02:44:16 CDT