Subject | Re: [ib-support] The dreaded foreign key creation error |
---|---|
Author | Martijn Tonies |
Post date | 2002-01-03T15:48:23Z |
--
Martijn Tonies
Upscene Productions
InterBase Workbench - The Developer Tool for InterBase
http://www.interbaseworkbench.com
"Experience is what you get when you didn't get what you wanted"
"Helen Borrie" <helebor@...> schreef in bericht
news:5.1.0.14.0.20020104023117.02a45c60@......
NEVER make a primary key do double action as a foreign key. If I want a
foreign key, I create a column for it, i.e. design the database before you
create it. It doesn't cost much and it keeps keys "functionally pure".
RELATIE holds companies that are somehow related to the application owner.
These companies can have several different functions - LEVERANCIER is
someone who sells goods to application owner. And every LEVERANCIER is a
RELATIE - therefore, every record in LEVERANCIER can be identified by it's
unique RelatieID - hence, both the PK and FK on the column... Is this wrong?
Martijn
Martijn Tonies
Upscene Productions
InterBase Workbench - The Developer Tool for InterBase
http://www.interbaseworkbench.com
"Experience is what you get when you didn't get what you wanted"
"Helen Borrie" <helebor@...> schreef in bericht
news:5.1.0.14.0.20020104023117.02a45c60@......
> At 04:20 PM 03-01-02 +0100, you wrote:in
> >Hi all,
> >
> >Perhaps we all know the error:
> >
> >My metadata was this:
> >
> >Table "RELATIE"
> >
> >RelatieID PK
> >... more columns ...
> >
> >Table "LEVERANCIER"
> >
> >RelatieID PK, FK to RELATIE
> >... more columns ...
> >
> >Table "ORDERREGEL"
> >
> >LeverancierID FK to LEVERANCIER
> >
> >Creating this constraint gave me the error that some index wasn't defined
> >the tables and a trigger raised an exception bla bla...because
> >
> >A common cause for this error is have an index defined on a primary key
> >column. In this case, the index was created by the system - namely
> >of the FK from LEVERANCIER to RELATIE.determined by the need to work around your problem, but by aesthetics) is to
> >
> >Dropping this FK results in removing the index and the second FK (from
> >ORDERREGEL to LEVERANCIER) could be created without problems. Next up:
> >creating the FK from LEVERANCIER to RELATIE. All went well...
> >
> >It is a workaround for a strange problem -- comments, anyone?
>
> Well, you won't like it, probably..but my rule (incidentally NOT
NEVER make a primary key do double action as a foreign key. If I want a
foreign key, I create a column for it, i.e. design the database before you
create it. It doesn't cost much and it keeps keys "functionally pure".
>I think it is functionally pure.
> :)
>
> Helen
RELATIE holds companies that are somehow related to the application owner.
These companies can have several different functions - LEVERANCIER is
someone who sells goods to application owner. And every LEVERANCIER is a
RELATIE - therefore, every record in LEVERANCIER can be identified by it's
unique RelatieID - hence, both the PK and FK on the column... Is this wrong?
Martijn