Foreign key references are present for the record

[DevStar]

Beim Löschen der Client-Tabelle zu meiner Master-Tabelle, bekomme ich folgende Fehlermeldung:

SQL-Code:

Foreign key references are present for the record

Was will Firebird mir damit sagen?
Hat jemand eine Idee, wie sich das umgehen läßt?

Kennt jemand überhaubt diesen Fehler? Habe vergebends gegoogelt.

LG DevStar

[Hansa]

Das ON CASCADE ist falsch eingestellt, oder der DS ist noch active.

[DevStar]

Zitat:

Zitat von Hansa

Das ON CASCADE ist falsch eingestellt, oder der DS ist noch active.

Das stimmt

SQL-Code:

on delete CASCADE

, denn da tritt der Fehler auf.
Stelle ich auf SET NULL oder DEFAULT um, dann wir der Datensatz in meinem View ignoriert, dan ist er weg und wird nicht mehr angezeigt.

In der Client-Tabelle sind Bezeichnungen hinterlegt, da ist ja Quatsch, wenn diese gelöscht werden, das dann der Datensatz in der Mastertabelle keine Bezeichnung hat.

Also ist CASCADE richtig. Nur müsste ich den Fehler abfangen.

Delphi-Quellcode:

ShowMessage ('Eintrag kann nicht gelöscht werden, da er in Tabelle 1 verwendet wird.');

Der Witz ist nur, bei CASCADE ist mein Datensatz in der MAster-Tabelle komplett weg.

Oder denke ich ganz falsch mit meiner Datenbank?

[Hansa]

Zitat:

Zitat von DevStar

Zitat:

Zitat von Hansa

Das ON CASCADE ist falsch eingestellt, oder der DS ist noch active.

Also ist CASCADE richtig. Nur müsste ich den Fehler abfangen.

Der Witz ist nur, bei CASCADE ist mein Datensatz in der MAster-Tabelle komplett weg.

Oder denke ich ganz falsch mit meiner Datenbank?

Halb zumindest. Wieso ist das CASCADE denn richtig ? Das läuft so : Master-DS wird gelöscht und dann werden alle untergeortneten DS auch gelöscht, also die Details. Ich würde das mal im IBExpert ausprobieren. Deshalb auch der zweite Hinweis. Was sagt uns denn das "is present" ? Das übersetze ich jetzt aber nicht.

[mkinzler]

CASCADE bedeutet, dass beim Löschen des Mastersatzen (z.B. Rechnung) alle Detailsätze ( z.B. Rechnungspositionen) automatisch mitgelöscht werden. Ist imho aber eine gefährliche Option.

[dfried]

Zitat:

Zitat von mkinzler

CASCADE.... Ist imho aber eine gefährliche Option.

Naja, wenn man weiss was man tut kanns auch sehr nützlich sein.

[DeddyH]

Zitat:

Zitat von dfried

Naja, wenn man weiss was man tut kanns auch sehr nützlich sein.

Aber nur dann :mrgreen:.

[Hansa]

Er hat das hier gefragt :

Zitat:

Zitat von DevStar

Beim Löschen der Client-Tabelle zu meiner Master-Tabelle, bekomme ich folgende Fehlermeldung: ...

Das ist also das Gegenteil von ON DELETE CASCADE. Und das habe ich nur in den Raum geworfen, weil es irgendwie schon passt. Aber eben leider nicht so richtig für den konkreten Fall.

Trotzdem noch hierzu :

Zitat:

Zitat von mkinzler

CASCADE bedeutet...Ist imho aber eine gefährliche Option.

Was wäre wenn der Rechnungskopf gelöscht wird, ohne ALLE Detaildaten zu löschen ? Tja, die bleiben dann als Datensatzleichen in der DB und müssen irgendwie, irgendwann (irgendwo :lol: ) von Hand gelöscht werden. Da die Daten ja hoffentlich nicht öffentlich zumindest über IDs zugänglich sind, wird das aus dem Programm raus echt schwierig. Man könnte halt einen Punkt einführen : "alle verwaisten Detail-Datensätze ohne Master - ID löschen". Und dann ? Man hätte sich tatsächlich die Wörter ON DELETE CASCADE gespart. Leichen im Keller sind immer schlecht. :mrgreen:

[mkinzler]

Es gibt auch andere Möglichkeiten: Manuelles Löschen im Code oder Umlenken auf Dummy-Rechnung o.ä. Ich habe auch nicht gesagt das diese Option schlecht ist; man sollte sie halt wohlüberlegt einsetzen. Das Beispiel mit der Rechnung war ja auch ein Pro Beispiel; ein Contra-Fall wäre die Beziehung von Rechnungspositionen zu Artikeln.

[Hansa]

Zitat:

Zitat von mkinzler

...oder Umlenken auf Dummy-Rechnung o.ä...Das Beispiel mit der Rechnung war ja auch ein Pro Beispiel; ein Contra-Fall wäre die Beziehung von Rechnungspositionen zu Artikeln.

Na gut, das Umlenken lasse ich mir ja noch gefallen. Nur, das Contra-Beispiel ist genauso kontraproduktiv. :mrgreen: Was nützt es mir denn, einen Artikel zwar zu löschen, aber nicht die Rechnungspositionen, auf denen der vorkommt ? Dann hätte man Rechnungspositionen ohne Artikelnr., von denen keiner mehr weiß, was der Kram soll. Nene, wenn schon löschen, dann aber richtig. Eben ohne Leichen in der DB zurückzulassen, die mühsam einzeln entsorgt werden müssen. *grusel*

[mkinzler]

Dann veränderst du alte Rechnungen!!! Deshalb sollte man in diesem Fall keine Löschregel verwenden!

[Hansa]

Ne Markus, da lasse ich nicht mit mir reden. Wenn gelöscht werden muss, dann richtig und basta. :shock: Rechnungen sind als Beispiel sowieso etwas ungeeignet, weil es nur noch eine Frage der Zeit ist, bis einer sagt, die dürften gar nicht gelöscht werden wegen Finanzamt. 8) Um dem zuvorzukommen : was, wenn ich einen Artikel löschen will, der seit über 10 Jahren nicht mehr verkauft wird ? Dann muss aber wirklich alles aus der DB verschwinden, was irgendwie mit dem zu tun hat. Jo, basta. :mrgreen:

[mkinzler]

Also dann sind wir in diesem Punkt halt anderer Ansicht

[marabu]

Hallo,

Zitat:

Zitat von DevStar

Beim Löschen der Client-Tabelle zu meiner Master-Tabelle, bekomme ich folgende Fehlermeldung: Foreign key references are present for the record ...

die Client-Tabelle wird sicher einen Fremdschlüssel auf die Master-Tabelle halten und solange dieses Constraint existiert kann die Tabelle nicht entfernt werden. Also zuerst alle Constraints entfernen und dann DROP TABLE.

Grüße vom marabu

[p80286]

Hallo Hansa,

Zitat:

Ne Markus, da lasse ich nicht mit mir reden. Wenn gelöscht werden muss, dann richtig und basta

Da bin ich ganz Deiner Meinung!

Zitat:

: was, wenn ich einen Artikel löschen will, der seit über 10 Jahren nicht mehr verkauft wird ?

Garnichts löschen! Das sind ganz reale Daten, die in der Vergangenheit eine Berechtigung hatten! Gelöscht werden dürfen nur Daten die keine Berechtigung haben und keinen Bezug zu anderen, realen Daten (sollte bei Spieldaten allerdings nicht vorkommen!) z.B. Spiel oder Test-Daten, davon gibt es in den meisten Datenbanken genug. Aber alles was einen konkreten Hintergrund hat, muß in einer DB vorhanden bleiben!

Es sei denn Deine DB wird nur benutzt um irgendwo anders vorhandene Daten neu zu organisieren, dann wäre das nach meinem Verständnis aber keine "Datenbank" sondern eine "Datensammelstelle".

Gruß
K-H

[mkinzler]

Zitat:

Garnichts löschen! Das sind ganz reale Daten, die in der Vergangenheit eine Berechtigung hatten! Gelöscht werden dürfen nur Daten die keine Berechtigung haben

Und deshalb ist für mein Beispiel eine kaskadierende Löschregel fehl am Platze

[DevStar]

Zitat:

Zitat von marabu

Hallo,

Zitat:

Zitat von DevStar

Beim Löschen der Client-Tabelle zu meiner Master-Tabelle, bekomme ich folgende Fehlermeldung: Foreign key references are present for the record ...

die Client-Tabelle wird sicher einen Fremdschlüssel auf die Master-Tabelle halten und solange dieses Constraint existiert kann die Tabelle nicht entfernt werden. Also zuerst alle Constraints entfernen und dann DROP TABLE.

Grüße vom marabu

Habe es jetzt so gelöst, dass ich die Exception abfange und eine Meldung ausgebe, das dieser Daznsatz nicht gelöscht werden kann, da er noch verwendet wird.

Danka an alle.

[marabu]

Moin,

Zitat:

Zitat von DevStar

Habe es jetzt so gelöst, dass ich die Exception abfange und eine Meldung ausgebe, das dieser Daznsatz nicht gelöscht werden kann, da er noch verwendet wird.

DROP TABLE war wohl ein Missverständnis.

Zitat:

Zitat von DevStar

Beim Löschen der Client-Tabelle zu meiner Master-Tabelle, bekomme ich folgende Fehlermeldung ...

Sorry, aber darunter habe ich als native speaker DROP TABLE und nicht DELETE FROM TABLE WHERE verstanden. In deinem Fall geht es ja wohl nur um einzelne Datensätze.

Wenn deine anderen Formulierungen nicht auch irreführend sind, dann hast du einen Fehler in deinen DRI Constraints, vermutlich hast du Master und Detail verwechselt. Das Abfangen des Fehlers bei gescheitertem DELETE vergleiche ich mit dem Kauf eines Eimers bei einem Leck in der Wasserleitung - wenn du verstehst, was ich meine.

Freundliche Grüße

[DeddyH]

Nochmal zum Allgemeinverständnis anhand eines Beispiels. Angenommen, wir haben eine Stammdatentabelle mit Augenfarben und eine Detailtabelle mit Personen. In der Personentabelle ist die Augenfarbe als Fremdschlüssel auf die Augenfarbentabelle referenziert.

Code:

Augenfarben:

ID  |  Bezeichnung
1      blau
2      braun
3      grün


Personen:

ID  |  Name  |  Augenfarbe
1      Meier    1
2      Müller   2
3      Schulze  3

Was soll nun mit den Personen geschehen, wenn z.B. die Augenfarbe blau gelöscht wird?

1. Gar nichts, Löschen bei existierenden Referenzen nicht möglich (Standard)
2. Die Referenz wird genullt (ON DELETE SET NULL)
3. Der Detaildatensatz wird ebenfalls gelöscht (ON DELETE CASCADE)

Daten nach Löschen:

Fall 1: siehe oben, Fehlermeldung
Fall 2:

Code:

Augenfarben:

ID  |  Bezeichnung
2      braun
3      grün


Personen:

ID  |  Name  |  Augenfarbe
1      Meier    NULL
2      Müller   2
3      Schulze  3

Fall 3:

Code:

Augenfarben:

ID  |  Bezeichnung
2      braun
3      grün


Personen:

ID  |  Name  |  Augenfarbe
2      Müller   2
3      Schulze  3

Man muss sich also bereits bei der Planung der DB Gedanken darüber machen, welchen dieser 3 Fälle man anstrebt. Wie bereits in diesem Thread angedeutet macht es dabei schon einen Unterschied, ob es sich um Spielstände (nicht für die Ewigkeit gedacht) oder Rechnungen (Daten müssen zwecks Prüfung erhalten bleiben) handelt.

Sollte ich das jetzt falsch dargestellt haben, bitte ich um sofortige Korrektur.

[edit] Nachtrag: Wenn man kaskadiert, muss man das allerdings auch durchgängig tun. Sollte es also weitere Tabellen geben, die sich auf Personen beziehen, muss die Personentabelle auch kaskadierend definiert sein, sonst ist das Löschen ebenfalls nicht möglich. Das zieht sich solange durch, bis es keine Referenzen mehr gibt. Hier liegt auch die große Gefahr dabei: möglicherweise löscht man so Daten, an die man gar nicht gedacht hatte. [/edit]