Alter Spalten-Datentyp mit Primärschlüssel

Sie müssen NOT NULL explizit in ALTER TABLE ... ALTER COLUMN angeben, andernfalls wird standardmäßig NULL zugelassen. Dies ist in einer PK-Spalte nicht erlaubt.

Das Folgende funktioniert gut.

Wenn der NOT NULL weggelassen wird, gibt es den folgenden Fehler

Ein paar Dinge, die Sie in Ihrem programmatischen Ansatz beachten sollten, ist, dass Sie alle Fremdschlüssel, die auf die Spalten ReferenceID verweisen, vorübergehend löschen und sicherstellen müssen, dass Sie NOT NULL nicht einschließen. für (Nicht PK) ReferenceID Spalten, die derzeit sind, können als Nullwerte verwendet werden.

BEARBEITEN Diese Lösung wird benötigt, wenn Sie eine verworrene Datenbank mit einer Mischung aus varchar (6) und char (6) Spalten haben, die durch eine Entwicklung über 10 Jahre verursacht wird (mit genügend Änderungen der Regierungspolitik zu dazu führen, dass jeder Versuch eines "guten Datenbankentwurfs" irgendwann zum Erliegen kommt.) ENDE BEARBEITEN

An diejenigen, die gesagt haben, ich müsste den PK fallen lassen und neu erschaffen, du hattest Recht. Indizes und Fremdschlüssel mussten ebenfalls gelöscht und neu erstellt werden.

Glücklicherweise gab es eine überschaubare Anzahl von Indizes und FKs, also behandelte ich diese als 'außergewöhnlich' und löschte sie alle nacheinander am Anfang des Skripts und fügte sie nacheinander wieder hinzu. am Ende des Skripts (siehe die beiden Abschnitte in / * * / unten).

Der Hauptteil des SQL-Skripts tippt dann vollständige Details zu den FKs in eine temporäre Tabelle, durchläuft dann jeden Tabellennamen, löscht den FK, ändert den Datentyp und fügt den FK erneut hinzu.

Die SQL-Strings, die zusammengestellt werden, sind im folgenden Skript PRINT. Wenn Sie beabsichtigen, dies wiederzuverwenden (keine Garantien, etc., bla bla), kommentieren Sie diese, um bis zu 50% der Ausführungszeit zu knacken.

Sie müssen die ALTER -Anweisung als dynamisches SQL ausführen: Erstellen Sie die Anweisung als SQL-Zeichenfolge und übergeben Sie sie an sp_executesql .

Aus meiner Erfahrung mit Datenbanken über 30 Jahre besteht die eine Konstante darin, dass Sie die Struktur jeder Datenbank, mit der Sie arbeiten, ständig ändern müssen, da sich die Datenanforderungen ändern. Darüber hinaus gibt es viele Fälle, in denen ein Primärschlüssel mit automatischer Inkrementierung nicht besonders geeignet ist, insbesondere wenn Sie sicherstellen möchten, dass die Daten direkt über das DBMS (z. B. SQL Server) verfügbar sind, wenn das Programm die Datenbank verwendet nicht länger verfügbar. Einer der großen Schwachpunkte des Datenbankmanagements ist die übliche Undurchdringlichkeit der Datenbank nach dem Aussterben des Programms - etwas, das dem Prinzip der Langzeitdatenverwaltung völlig zuwiderläuft.

Daher ist die Unfähigkeit, die Größe eines Primärschlüsselfeldes leicht zu ändern, NICHT wegen eines schlechten Datenbankdesigns, sondern weil die DBMS- und SQL-Werkzeuge zur Handhabung der Datenbank grob unzureichend sind, klar von Programmierern mit einem theoretischen Ansatz entworfen ein wirkliches Verständnis der realen Welt. Andere Beispiele für solche Programmierfehler sind Array - Indizes, die von 0 statt 1 beginnen (die Anzahl der Fehler, die entstehen, wenn 1 vom Index zum Zählwert addiert oder subtrahiert wird, sind Legion), die Unfähigkeit für numerische Variablen, NULL - Werte zu verarbeiten usw Ich freue mich auf den Tag, an dem die Änderung der Datenbankstruktur als Mainstream-Notwendigkeit betrachtet wird, anstatt sich aus dem sogenannten schlechten Datenbankdesign zu ergeben.