none
Spaltenbreite nachträglich ändern bei Foreign Key Contraints RRS feed

  • 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

    Freitag, 6. Juli 2018 09:46

Antworten

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

    Freitag, 6. Juli 2018 09:56
    Moderator
  • 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.

    Freitag, 6. Juli 2018 10:49
  • 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

    Freitag, 6. Juli 2018 11:23
  • 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

    Freitag, 6. Juli 2018 11:28
  • 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.

    Freitag, 6. Juli 2018 11:46
  • Ich meinte mit löschen auch das entfernen der Foreign Key.

    Freitag, 6. Juli 2018 12:26
  • @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]
    GO

    Wenn 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

    Freitag, 6. Juli 2018 12:31
  • Korrekt, Prüfe aber die anderen Tabellen ggf. auf Primary Key, was durchaus üblich sein kann.
    Freitag, 6. Juli 2018 12:41
  • Hallo Hans,

    wenn du nicht im produktiven Umfeld tätig bis kann das auch der Tabellen Designer für dich übernehmen - du musst nur die Option entfernen...

    Grüße Volker

    Dienstag, 17. Juli 2018 14:44
  • Ein Alter Table ist ja gerade keine Neuerstellung. Somit dürfte dieser Schalter eigentlich wirkungslos sein.
    Ein Neuerstellen würde ja kompletter Datenverlust bedeuten.
    Dienstag, 17. Juli 2018 15:04
  • 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

    Dienstag, 17. Juli 2018 16:10
    Moderator
  • 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

    Mittwoch, 18. Juli 2018 06:08
  • 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.

    Mittwoch, 18. Juli 2018 07:50
  • 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

    Mittwoch, 18. Juli 2018 08:03