Den Typ einer Spalte nachträglich ändern. Daten sollen bestehen bleiben

[Der schöne Günther]

Ich habe das gemacht, was man laut diesem schlauen Thread:
http://www.delphipraxis.net/187239-a...er-zahlen.html
niemals tun sollte: Bezeichner die heute nach Zahlen aussehen als Integer speichern. Ich habe extra zwei mal gefragt, aber jetzt sollen bitte doch Buchstaben drin vorkommen können.

An sich ist das einfach. Sage ich einfach

Code:

ALTER TABLE "meineTabelle"
ALTER COLUMN "meineSpalte" "meineSpalte" CHAR(40)

wird aus meiner Spalte vom Typ "ShortInteger" eine "CHAR(40)"-Spalte. Aber Moment, was passiert mit den Daten die da schon drin stehen? Eine 5 wird zu einer "5" , eine 0 zu einer "0" . Eigentlich kann hier nichts falsch laufen.

Aber wer garantiert mir das? Selbst den Rückweg macht meine "SAP Advantage Database"-Datenbank ohne Probleme: Aus einer "5" wird eine 5 , aus einer "5a" wird eine 5 und aus "Delphi" wird eine 0 ! Das ist schon etwas gruselig. Meine Frage: Gibt es einen Standard von dem man halbwegs ausgehen kann? Macht da jedes DBMS anders? Ich finde in meiner Doku zu Typkonversionen nichts.

[himitsu]

Man kann da bestimmt auch eine Konvertierungsfunktion mit angeben, welche man für eine explizite Konvertierung nutzen kann.
In deiner Richtung sollte die Standardkonvertierung aber ausreichen.

Wenn meineSpalte INTEGER ist und meineSpalte::VARCHAR bzw. CAST(meineSpalte AS VARCHAR) funktioniert, oder wie auch immer ein CAST geht, dann kann man die manuelle Konvertierung weglassen.

Ansonsten ginge auch vorher ein UPDATE, wo alles "Ungültige" entfernt wird.



Aber eigentlich würde ich auch erwarten, daß bei unmöglicher Konvertierung (veränderte Inhalte, bzw. Datenverlust) ein Fehler geworfen wird.
Also z.B. auch bei VARCHAR(5) -> VARCHAR(10) = OK, aber VARCHAR(10) -> VARCHAR(5) = Fehler, wenn ein Text länger als 5 ist.

SQL-Code:

-- in PostgrSQL
ALTER TABLE [ ONLY ] name [ * ] ALTER [ COLUMN ] column [ SET DATA ] TYPE data_type [ COLLATE collation ] [ USING expression ]

SQL-Code:

ALTER TABLE meineTabelle
ALTER COLUMN meineSpalte
TYPE CHAR(40)
USING cast(meineSpalte AS CHAR(40))  -- upper(trim(substr(meineSpalte, 3, 5)))

entspricht

SQL-Code:

UPDATE  meineTabelle
SET meineSpalte = cast(meineSpalte AS CHAR(40));

ALTER TABLE meineTabelle
ALTER COLUMN meineSpalte
TYPE CHAR(40);

[Lemmy]

was ist daran gruselig? Aber wenn Du niemandem traust (keine schlechte Eigenschaft beim programmieren), dann mach es doch selbst:

1. neue Spalte anlegen im Wunschtyp als tmpIrgendwas
2. alte Spalte in neue Spalte konvertieren (z.B. führende 0 anfügen,...)
3. alte Spalte löschen
4. neue Spalte anlegen
5. Daten aus der temporären Spalte in die endgültige Spalte verschieben
6. temp-Stalte löschen
7. ggf. witere Aktionen (Index,...)

[p80286]

Ich würde es etwas einfacher machen
1) neue Spalte anlegen
2) alte Spalte in neue Spalte konvertieren (Führende Nullen/Tausendertrennzeichen etc.)
3) Indizes anpassen falls notwendig/Trigger/Constraints oder 1a)
...
Irgendwann einmal alte Spalte löschen.
Den alten Namen für die neue Spalte weiter benutzen würde ich nicht, da es dann mal unbeabsichtigt knallen könnte wenn Du eine Typänderung vergessen hast.

Gruß
K-H

[himitsu]

Zitat von p80286:

Den alten Namen für die neue Spalte weiter benutzen würde ich nicht, da es dann mal unbeabsichtigt knallen könnte wenn Du eine Typänderung vergessen hast.

Aber so bekommt man nicht mit, wenn man irgendwo im Code noch auf die alte Spalte geht.

[p80286]

Zitat von himitsu:

Aber so bekommt man nicht mit, wenn man irgendwo im Code noch auf die alte Spalte geht.

Auch'n Argument, also nicht irgendwann, sondern sofort die alte Spalte löschen.

Gruß
K-H

[Der schöne Günther]

Zitat von p80286:

Den alten Namen für die neue Spalte weiter benutzen würde ich nicht, da es dann mal unbeabsichtigt knallen könnte wenn Du eine Typänderung vergessen hast.

Das verstehe ich nicht. Meinst du wenn ich, mittels Delphis wunderbarem Variant -Typ an X Stellen auf dieses Feld zugreife und jetzt vergesse, alle zu erwischen? Das würde mir doch zur Laufzeit genauso um die Ohren fliegen wie wenn ich mit FieldByName(..) auf ein nicht mehr vorhandenes Feld zugreife.

[p80286]

Na irgendwann mußt Du ja Farbe bekennen und dich für Integer oder String entscheiden und spätestens dann macht es Plopp.
Da ich Variant wann immer es geht vermeide, habe ich das Vergnügen halt früher.

Gruß
K-H

[jobo]

Ich schließe mich himitsu an.
Update auf Zielinhalt, dann den Typ der Spalte ändern.
Es kann aber sein, dass es tatsächlich Systeme gibt, die das nicht mögen. Dann bleibt nichts als der Umweg über eine zusätzliche Spalte.

Wenn man keine Altlasten haben möchte, lieber alles sofort durchgehend umstellen.

[himitsu]

Wenn beim Umstellen "Datenverlust" entsteht, also z.B. aus "a1" eine 1 wird, dann eventuell eine Kopie der Daten behalten.
* Spalte umbenennen (hier bleiben aber eventuelle Referenzen bestehen)
* neue Backup-Spalte und alte Spalte löschen/ändern
* oder einfach als DB-Backup

Aber die Spalte unter dem bekannten Namen besser weg, damit man Fehler findet.
Muß etwas weiter auf die alte Spalte gehen, dann explizit auf das Backup umstellen und vielleicht noch einen Synchro-Trigger, der die Spalten abgleicht.

Ob man nun die neue Spalte neu erstellt und die Alte löscht, oder die Alte nur Konvertiert, ist dann geschmackssache, bzw. hängt vom DBMS ab.

IMHO