--
"Anurag Varma" <avdbi_at_hotmail.com> wrote in message
news:85ndc.16595$e17.1017_at_twister.nyroc.rr.com...
>
> "Walt" <walt_askier_at_yahoo.com> wrote in message
news:4075D7DF.641A5B81_at_yahoo.com...
> > Anurag Varma wrote:
> --snip--
> > > Incidently you can skip the export of triggers in exp .. but cannot
prevent the import
> > > in imp. So that you would need to drop them after import.
> >
> > I get essentially the same behavior. I don't really care about the fact
> > that it imports the indexes for the table even though I've told it not
> > to. Likewise with the grants.
> >
> > But the trigger import seems to be a real problem. It creates a trigger
> > in the schema2 that acts on the table in schema1. The result is that
> > schema2.mytable has no trigger (not really a problem) and
> > schema1.mytable winds up with two triggers on it, one in each schema.
> > Is this a known bug or what?
> >
> >
> > Note: I'm diagnosing this by using show=y, rows=n and looking at the
> > SQL.
> >
> > --
> > //-Walt
> > //
> > //
>
> I'm not sure why you see indexes being imported when you have stated
indexes=n and constraints=n.
> That is something I've never seen and you might be wrong in stating that.
> However, with triggers, yes I'd agree with you. However the behaviour of
schema1 getting the trigger is
> probably related to the fact that you created the trigger using a
statement like this:
> create or replace trigger trig_name on schema1.tablename
>
> instead of
>
> create or replace trigger trig_name on tablename ...
>
> In that case the import will create the trigger as you specified it
(schema1.tablename). I believe,
> this is what you are seeing .. and I do not think this could be called a
bug.
>
> Anurag
>
>
>
Fyi... a search in Metalink on 1502847 will show 3 entries where this number
is referred to as a bug. All the entries deal with this problem.
Received on Fri Apr 09 2004 - 01:54:57 CDT
