Benutzer mit den meisten Antworten
Spaltenbreite nachträglich ändern bei Foreign Key Contraints

Frage
-
Hallo zusammen,
ich habe drei SQL Tabellen die zueinander Foreign Key Contraints haben.
Es wurde nun festgestellt dass eine Spalte "Kennzeichen" mit varchar(5) auf 10 erweitert werden muss.
Wenn ich es in SSMS versuchte kommt ständig eine Warnmeldung und dass die anderen Tabellen gelöscht und wieder neu erstellt werden müssen.
Wie kann man die Anforderung am besten bewerkstelligen?
Danke für jeden Hinweis.
Gruss
Hans
Antworten
-
Man muss die referentiellen constraints entfernen, die Aktion durchführen (dabei müssen dann alle betroffenen Tabellen angepasst werden) und den constraint anschließlend wieder erstellen.
Natürlich sollte die Datenbank dabei nicht in Betrieb sein.
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 10. Juli 2018 10:07
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 24. Juli 2018 12:52
-
Das Management Studio geht da immer sehr rigoros vor. Am besten macht man die Änderung (wie oben angeregt) per T-SQL:
1.) ALTER TABLE DROP CONSTRAINT
2.) ALTER TABLE ALTER COLUMN (für alle Tabellen)
3.) ALTER TABLE ADD CONSTRAINT
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 10. Juli 2018 10:07
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 24. Juli 2018 12:52
Alle Antworten
-
Hallo Hans,
die Spalte "Kennzeichen" ist der Fremdschlüssel in den anderen Tabellen?
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport -
Man muss die referentiellen constraints entfernen, die Aktion durchführen (dabei müssen dann alle betroffenen Tabellen angepasst werden) und den constraint anschließlend wieder erstellen.
Natürlich sollte die Datenbank dabei nicht in Betrieb sein.
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 10. Juli 2018 10:07
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 24. Juli 2018 12:52
-
Das Management Studio geht da immer sehr rigoros vor. Am besten macht man die Änderung (wie oben angeregt) per T-SQL:
1.) ALTER TABLE DROP CONSTRAINT
2.) ALTER TABLE ALTER COLUMN (für alle Tabellen)
3.) ALTER TABLE ADD CONSTRAINT
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 10. Juli 2018 10:07
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Dienstag, 24. Juli 2018 12:52
-
Hallo Stefan,
ja genau:
Im Prinzip
Haupttabelle A mit Spalte
"CountryCode" (varchar5)
"Country"Tabelle B
"CountryCode", "Name", "WeitereSpalten"
Tabelle C
"CountryCode" , "WeitereSpalten"
und CountryCode ist dann der Fremdschlüssel für die anderen Tabellen.
Vermutlich muss man die Schlüssel vor der Änderung löschen?
Kann man eigentlich den Schlüssel vor dem Löschen irgendwie als Script sichern? Dann wäre es einfacher beim hinterher wieder einrichten
Gruss
Hans
-
Nein, du brauchst nichts löschen.
Entferne die Constraints wie angegeben, ändere die Spalte, die Daten bleiben erhalten, setze die Constraints wieder neu.
Natürlich gehört neben dem Foreign Key der Primary Key oder Check Constraints auf dem Feld genauso dazu. -
@Christoph
zu 3:
ist es wirklich nur mit dieser Zeile getan?
Wenn ich bei bestehenden Foreign Key klicke Script as Create dann wird mir etwas mehr angezeigt:
ALTER TABLE [dbo].[TabelleA] WITH NOCHECK ADD CONSTRAINT [FK_TabelleA_TabelleB] FOREIGN KEY([CountryCode])
REFERENCES [dbo].[TabelleB] ([CountryCode])
GO
ALTER TABLE [dbo].[TabelleA] CHECK CONSTRAINT [FK_TabelleA_TabelleB]
GOWenn ich mir das vorher sichere, dann den DROP mache, die Spalte ändere und dann wieder dieses Script ausführe müsste es ja eigentlich wieder stimmen oder?
Gruss
-
Beim Neuerstellen über das SSMS wird die Tabelle, wenn ich das noch richtig im Kopf habe, mit einem temprorären Namen mit der neuen Struktur aufgebaut, dann werden die Daten von der alten in die neuen Tabelle kopiert, die alte gelöscht und die neue Tabelle wieder mit dem Namen der Originaltabelle versehen.
Insbesondere bei großen Tabellen ist das aber natürlich schon ein Problem.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport -
Stefan,
das hast du richtig im Kopf - der Aufbau des vom SSMS generierten SQL ist bei solchen Änderungen eigentlich immer gleich:
- Temp Tabelle anlegen
- Constraints entfernen
- Daten im Temp Tabelle kopieren
- Tabelle löschen
- Tabelle neu anlegen
- Daten von Temp - Tabelle in "Neue Tabelle" kopieren
Der Schalter bewirkt lediglich, dass wenn das SSMS eine solche "Aktion" erkennt, dass diese ggf. verhindert wird - was insbesondere bei großen Tabellen durchaus sinnvoll ist. In Entwicklungsumgebungen ergibt dies, je nach Arbeitsweise, aber durchaus Sinn.
Grüße Volker
-
Fehlt da nicht noch der Schritt am Ende "Constraints hinzufügen", oder auch Trigger entfernen und Hinzufügen?
Sonst wäre das Datenmodell ja kaputt.
- Bearbeitet Der Suchende Mittwoch, 18. Juli 2018 07:51
-
Da hast du natürlich Recht (hatte ich unter dem Punkt "Tabelle neu anlegen" impliziert ...
Je nach Änderungsart und SSMS Version wird auch so vorgegangen:
- Constraints aus "alter Tabelle" entfernen
- Temp Tabelle anlegen (neue Form und mit Constraints)
- Daten im Temp Tabelle kopieren
- "alte" Tabelle löschen
- Temp Tabelle umbenennen
Grüße Volker