Re: Imp-ish behavior :)

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_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] 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