Announcement

**Carsten Haberland** · 02.04.2003, 16:41

Hallo zusammen, 
nach einer umfangreichen Suche im Internet habe ich folgendes �ber diesen Fehler herausgefunden: 
Borland-Info 
Es ist ein bekannter Fehler, der immer dann auftritt, wenn der PRIMARY KEY der Tabelle Muster2 bereits auch als FOREIGN KEY auf einer anderen Tabelle referenziert. 
So, nun gabs es aber keinen FOREIGN KEY in Muster2. Da hab ich in einem russischen Forum das gleiche Problem gefunden, und nach Auswertung derer SQL-Statements gab es f�r mich folgende L�sung. 
L�sung durch russisches Forum 
Die Tabelle Muster2 hatte auf den PRIMARY KEY einen UNIQUE INDEX, der von Interbase immer angelegt wird, und einen zus�tzlichen DESCENDING UNIQUE INDEX, den ich selber angelegt habe. 
Nach dem Entfernen des zweiten INDEX konnte ich den FOREIGN KEY anlegen. Das neue Erzeugen des INDEX nach dem Anlegen des FOREIGN KEYs ging dann problemlos. 
Soweit sogut! Nun steht trotzdem noch folgende Frage im Raum: 
Wieso konnte Interbase meinen FOREIGN KEY nicht anlegen ohne das ich den besagten INDEX entfernt habe? 
MfG 
Carsten<br&gt

**Thomas Steinmaurer** · 02.04.2003, 20:46

Carsten, 
welche InterBase-Version verwendest Du? Macht es einen Unterschied wenn Du den DESCENDING INDEX nicht als UNIQUE deklarierst und anschlie�end den FOREIGN KEY Constraint anlegst? 
Gruss, 
Thoma

**Carsten Haberland** · 03.04.2003, 09:49

Hallo Thomas, 
also ich arbeite mit Interbase 6.0. 
Ich habe mal folgendes ausprobiert:<ul>
<li>drop index Muster2_idx;</li>
<li>create descending index Muster2_idx on Muster2(ID_Muster2); (kein unique)</li>
<li>alter table Muster add constraint Muster_FK foreign key(ID_Foreign) references Muster2(ID_Muster2);</li>
</ul>
Das scheint zu funktionieren, also lag es am unique. Nur kann ich mir darauf keinen Reim machen. 
MfG, 
Carsten<br&gt

**Thomas Steinmaurer** · 03.04.2003, 10:01

Hallo Carsten, 
also haben mich meine grauen Zellen doch nicht im Stich gelassen ;-). Mir war diesbzgl. etwas in Erinnerung, wenn auf einem Primary-Key zus�tzlich ein UNIQUE DESCENDING Index definiert wurde. Das UNIQUE ist f�r den zus�tzlichen Index nicht notwendig, weil dies bereits durch den PRIMARY KEY Constraint sichergestellt wird, aber das sollte keine negative Auswirkung auf das Anlegen eines FOREIGN KEYs haben, d.h. ich w�rde das als Bug bezeichnen. Welche InterBase Version genau? 6.0.1.0, 6.0.1.6 oder 6.0.2.0? 
Gruss, 
Thoma

**Carsten Haberland** · 03.04.2003, 10:14

Hallo Thomas, 
die genaue Interbase-Version ist 6.0.1.0. 
Also wenn das alles ein Bug ist, habe ich noch eine Frage. Wie im zweiten Kommentar erkl�rt, funktioniert es, wenn ich den Index erst nach dem Fremdschl�ssel anlege (auch als unique). Hat dieser Bug dann Auswirkungen auf die Performance und Funktionalit�t der Datenbank? 
MfG, 
Carsten<br&gt

**Thomas Steinmaurer** · 04.04.2003, 08:11

Hallo Carsten, 
> die genaue Interbase-Version ist 6.0.1.0 
wenn irgendwie m�glich unbedingt auf 6.0.1.6 updaten, da 6.0.1.0 eine sehr fr�he Version von IB 6.0 darstellt, und 6.0.1.6 als die stabilste IB 6.0 Open-Edition Version angesehen werden kann. 
Ich kann jetzt nicht mit Sicherheit sagen, ob z.B. der Optimizer verwirrt wird, wenn der DESCENDING Index auch als UNIQUE angelegt wurde. Ich w�rde Dir empfehlen einen zus�tzlichen DESCENDING Index auf einem Prim�rschl�sselfeld nicht als UNIQUE zu deklarieren, so mach ich es zumindest, weil die Eindeutigkeit bereits durch den PRIMARY KEY Constraint festgelegt wurde. 
Gruss, 
Thoma

**Carsten Haberland** · 04.04.2003, 08:48

Hallo Thomas, 
danke f�r die Tips. Ich werde dann mal sehen, dass ich die Interbase-Version update. 
Aber ich habe mich jetzt auch entschieden, dass ich die descending indexe nach dem Erzeugen der foreign keys anlege. Das klappt ja. 
MfG, 
Carsten<br&gt

Announcement

Fehler beim Anlegen eines FOREIGN KEY

Fehler beim Anlegen eines FOREIGN KEY

Comment

Comment

Comment

Comment

Comment

Comment

Comment