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

[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

[hoika]

Hallo,
man könnte ja die alte Spalte in 2 neue kopieren (für Backup zum Gucken mit dem gleichen Datentyp und Produktivbetrieb mit dem neuen Datentyp).

Zur Frage nach einem Standard:
eigentlich sollte Alter Column von jedem DB unterstützt werden,
aber ist halt nur eigentlich, also nicht wirklich.

Bei alten Firebirds musste man über die Systemtabellen gehen,
bei der BDE gab es das DbiDoRestructure, was das schön gekapselt hat ... hach, die gute alte Zeit ...


Heiko