Re: FOREIGN KEY

Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
> Welche Version? Und warum prüfst Du es nicht?

Die DB besteht aus ca. 60 Tabellen, und noch mal ca. FOREIGN KEY. Ich habe mir
mit gpAdminIII die Tabellen angesehen. Und danach gab es einen FOREIGN KEY
auf eine bestimmte Tabelle. Mein DB-Anwendung konnte aber ungestraft
Datensätze löschen.
Jetzt habe ich die DB noch mal mit psql untersucht und festgestellt das die
FOREIGN KEY in einer anderen Tabelle existieren und funktionieren, nur in dem
einen Fall, sagte psql auf einmal es gäbe für die Tabelle kein FOREIGN KEY.
Als ich den händisch noch mal nachgebaut habe, konnte meine DB-Anwendung auch
nicht mehr herum wüten.
Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer
zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der DB und
jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes mal
sage ich "ja" und trotzdem werde ich wieder nach dem Passwort gefragt.

Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie die
aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Update
wächst die Gefahr, das die Tabellen die durch eine Neuinstallation angelegt
werden, anders aussehen, als die, die den Update-Prozess durchlaufen haben.
Durch das Refactoring wurde das Problem auch noch verschärft.

Vielleicht muss ich für den Upgrade einfach Test schreiben um herraus zu
bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datensätze
schreiben, lesen und löschen. Oh, mich grausts... Nur allein das
Refactoring-Upgrade hat schon 1500 Zeilen SQL.

MfG

Olaf

--
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/