Bedingte Ausführung von ALTER Table in Skript?

Hallo,

wie kann ich in einem Skript folgenden Befehl fehlerlos einsetzen:

ALTER TABLE Test ADD COLUMN TestColumn;

Die Fortführung des Skripts sollte gewährleistet sein, selbst wenn die Spalte ‘TestColumn’ schon existiert.
Soweit ich aus Hilfe ersehen kann funktionieren Kontrollstrukturen (IF …THEN) und Fehlerbehandlung (EXCEPTION) nur in Funktionen, gibt es für Skripte was ähnliches?


MfG,
CUBa42

Du könntest dir ein Script (auch on the fly) schreiben, das diese Änderung nur dann vornimmt, wenn die Spalte noch nicht vorhanden ist …

Aber eigentlich sollte man vorher wissen, was in seiner Datenbank bereits existiert, das gehört zu einem Change Management.

He. he - vergaggeiern kann ich mir selber!
Das war doch genau die Frage, wie stelle ich in einem Skript fest ob eine Spalte schon vorhanden ist!

Aus dem zweiten Teil deiner Antwort schließe ich, dass jegliche bedingte Ausführungen und Exception-Handling grundsätzlich überflüssig sind, da, hätte man (wer?) schon immer alles richtig gemacht, dies natürlich nie notwendig ist. Schöne Welt, aber was mache ich wenn ich auf eine unbekannte Ausgangslage treffe? Soll ich dann auch nur einen ‘schlauen’ Spruch ablassen?
Nichts für ungut, aber ich wollte jetzt nicht wissen, dass du ein tolles ‘Change Management’ hast, davon habe ich konkret nichts.

Okay. Frag die Katalogtabellen ab. Das, was Du suchst, steht übrigens in pg_attribute. Das Problem wird weiterhin sein, dies bedingt auszuführen. Aber auch das geht - ads sagt (indirekt) wie.

Aus dem zweiten Teil deiner Antwort schließe ich, dass jegliche bedingte Ausführungen und Exception-Handling grundsätzlich überflüssig sind, da, hätte man (wer?) schon immer alles richtig gemacht, dies natürlich nie notwendig ist. Schöne Welt, aber was mache ich wenn ich auf eine unbekannte Ausgangslage treffe? Soll ich dann auch nur einen ‘schlauen’ Spruch ablassen?
Nichts für ungut, aber ich wollte jetzt nicht wissen, dass du ein tolles ‘Change Management’ hast, davon habe ich konkret nichts.

Du könntest aber aus den Erfahrungen anderer lernen, anstatt diese anzuflaumen.

Andreas

Hast du überhaupt eine Ahnung, was mit Change Managenemt gemeint ist? Wenn nicht, hör auf, hier rumzuflamen.

Natürlich ist nichts perfekt, kein Projekt hat von Anfang an die perfekte Datenbank Basis. Aber man sollte doch versuchen, auf mehr als einem Rechner einen gleichen Stand für ein Projekt zu erreichen. Sprich: wenn ich ein Projekt mit Revision 12 heute auf Rechner A aufsetze, will ich das aus den gleichen Sourcen morgen auch auf B aufsetzen können und die Datenbank soll hinterher genauso aussehen (Stand 12).

Wenn ich nun Änderungen an meinem Projekt habe und bringe Version 13 heraus, dann weiss ich genau: ich muss auf jedem beteiligten Rechner die Änderungen von 12 nach 13 ausführen und die gelingen oder etwas anderes ist nicht in Ordnung. Klar soweit?

So, bring so etwas in dein Projekt und alle deine Probleme erledigen sich von alleine. Bis dahin: mit meinem Vorschlag hättest du dein Problem umgehen können, aber da du so freundlich zu mir warst, werde ich auch freundlich sein und dir dafür nicht weiter helfen.

Das Projekt zuerst einmal dokumentieren.

Dein Problem ist, das du nicht zwischen DDL und Datenänderungen unterscheidest. Zu Änderungen der DDL kommen grundsätzlich Änderungen der beteiligten Applikationen … und die müssen auch wiederum dokumentiert werden.

Wenn du mir erzählen möchtest, das ihr nur just for fun Software schreibt ohne das vernünftig zu dokumentieren dann komm nicht hierher und jammere herum. Damit ist niemandem geholfen, am wenigsten euch.