Re: Imp-ish behavior :)

[Janine Sisk <janine@xxxxxxxxxx>]

It looks to be doing both - checking to see if the name is available, 
and then auto-generating a new one.

This reminds me of the time I tried to install some version of 8i 
without having X installed.  I used the command-line options for 
runInstaller telling it to run totally silently and to take it's inputs 
from a file, following the manual.  It probably would have worked, 
except that one of the first things the installer did was check to see 
if X was present and exit if it was not found. Even though it was 
running in a mode where X was not needed.  Aggravating, to say the 
least!  I haven't tried it again since then to see if it has been 
fixed;  we just install X on all servers, with my sys admin grumbling 
all the way.

janine

On Jul 1, 2005, at 6:32 AM, Powell, Mark D wrote:

> In my opinion where an PF, UK, or FK has an autogenerated name Oracle
> should not care on import if the name already exists.  It should 
> instead
> just generate a new autogenerated name and perform the uniqueness check
> on the constrained table column combination.  Oracle support would
> probably say this is expected behavior or a feature but I would call it
> a design logic bug.
>
> You can minimize this problem by always explicitly assigning a name to
> all namable objects upon creation.  So explicitly name your PK, UK, FK,
> and IOT indexes.
>
> IMHO -- Mark D Powell --
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Janine Sisk
> Sent: Thursday, June 30, 2005 6:44 PM
> To: oracle-l (E-mail)
> Subject: Imp-ish behavior :)
>
> I have a question for the collective wisdom of the list.  It's not
> hugely important but it's one of those things that can keep one awake 
> at
> night, wondering...
>
> I imp-orted a dump today, going from one copy of 8.1.7.4 to another.  I
> received "name already used by an existing constraint" on foreign key
> constraints on two different tables, something that has never happened
> to me before.  It was true that the two constraint names were already 
> in
> use;  they were each assigned to a not null constraint for the primary
> keys for two completely unrelated tables.  No problem there, I was able
> to create the constraints by hand, but in the process of figuring out
> what had happened I noticed something interesting.
>
> Each of the ALTER TABLE statements in the dump file specifies a name 
> for
> the foreign key constraint it is creating.  But none of the ones that
> were created successfully are actually using the specified names.
> For example, the other foreign key constraint on one of the tables I 
> had
> trouble with is called SYS_C003672 in the dump file, but in the schema
> where I loaded this dump, it's called SYS_C004360.  In other words, imp
> didn't actually use the name that was specified in the dump file;  it
> used it's own autogenerated name.  So why does it care whether the
> specified name is in use or not???
>
> janine
>
> --
> http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l

• References:
  • RE: Imp-ish behavior :)
    • From: Powell, Mark D

Other related posts:

Imp-ish behavior :)

RE: Imp-ish behavior :)

Re: Imp-ish behavior :)