pcfjkg
Goto Top

DROP Column schlägt fehl bei SQL SERVER

Mit ALTER TABLE könnnen z.B. in einer Tabelle auf einem SQL-SERVER Spalten hinzugefügt und/oder gelöscht werden. DROP einer Spalte schlägt jedoch fehl, wenn diese die mit IDENTITY PRIMARY KEY erzeugt wurde.

In der SQL-SERVER-Hilfe und im Forum habe ich Verschiedenes dazu gelesen und probiert; da es trotz dieser Hinweise nicht funktioniert, liegt es wahrscheinlich wahrscheinlich mal wieder an der Syntax, einem fehlenden (oder falschen) Zeichen usw.usf. Kann mir jemand zu Folgendem einen Tipp geben ?

ALTER PROCEDURE dbo.P_Test
AS
BEGIN
DROP TABLE T_Test
CREATE TABLE T_Test ( ZNr int identity primary key, dummy int)
ALTER TABLE T_Test DROP ZNr
END
Message: 'ZNr' ist keine Einschränkung. Das war wohl auch zu erwarten, aber

ALTER PROCEDURE dbo.P_Test
AS
BEGIN
DROP TABLE T_Test
CREATE TABLE T_Test ( ZNr int identity primary key, dummy int)
ALTER TABLE T_Test DROP CONSTRAINT ZNr
END
Message: 'ZNr' ist keine Einschränkung. Also, auf ein Neues:

ALTER PROCEDURE dbo.P_Test
AS
BEGIN
DROP TABLE T_Test
CREATE TABLE T_Test ( ZNr int identity primary key, dummy int)
ALTER TABLE T_Test DROP FOREIGN ZNr
END
Message: Falsche Syntax in der Nähe des FOREIGN-Schlüsselwortes

und noch einmal etwas anders (ohne identity)

ALTER PROCEDURE dbo.P_Test
AS
BEGIN
DROP TABLE T_Test
CREATE TABLE T_Test ( ZNr int primary key, dummy int)
ALTER TABLE T_Test DROP COLUMN ZNr
END
Message: Das Objekt 'PK__T_Test__D8FF7BA46545CD27D' ist vom Spalte-Objekt 'Znr' abhängig:

Soll wohl bedeuten, dass die PRIMARY KEY Eigenschaft vor den droppen entfernt werden soll. Nur: Wie macht man das ?


SQL-SERVER 2000 und SQL-SERVER 2008 verhalten sich gleich, kann ergo nicht an der Version liegen.

Who can help ?

thanks...

PCFJKG

Content-ID: 112982

Url: https://administrator.de/contentid/112982

Ausgedruckt am: 24.11.2024 um 04:11 Uhr

Netzheimer
Netzheimer 01.04.2009 um 15:45:51 Uhr
Goto Top
Hallo.

Als erstes würde ich die Anweisungen per 'go' trennen, sonst kann es sein dass der Server noch mit dem Löschen der alten Tabelle Test beschäftigt ist, obwohl er sie schon neu anlegen soll.

Für die ZNr empfehel ich: ZNr int identity(1,1) primary key not null -> erste Zahl Startwert, zweite Zahl erhöhen um 1; außerdem darf es keine NULL-Werte enthalten weil es ja primary key ist.

DROP FOREIGN kenne ich so nicht -> Vermutlich DROP CONSTRAINT ...

Der Ansatz mit erst anlegen und dann ALTER TABLE ist der Richtige.
PCFJKG
PCFJKG 03.04.2009 um 08:17:58 Uhr
Goto Top
Hallo Netzheimer,

zunächst Danke für die Antwort, habe natürlich heute Früh sofort getestet. Leider kommt auch bei der
Variante ZNr int identity(1,1) primary key not null beim ausführen die Meldung 'ZNr' ist keine Einschränkung.

Gibt es vielleicht noch eine Idee ?

... und nochmals danke für die Hilfe

PCFJKG
Biber
Biber 03.04.2009 um 09:17:36 Uhr
Goto Top
Moin PCFJKG,

vorab: ich vermag keinen konstruierbaren Anlass für ein derariges Vorgehen (Anlegen einer Tabelle mit PK und umgehendes Droppen des PK-Feldes) herzuleiten.

Aber wenn Du durch welche Unwägbarkeiten des Schicksals auch immer in diese Situation geraten sein solltest, dann reduzieren sich die Alternativen auf:
  • Schritt 1: die PRIMARY KEY-Constraint entfernen --> dazu musst Du die beim Namen nennen können
  • um den Namen der Constraint zu "wissen", kannst Du ihn entweder selbst festlegen beim Anlegen der Tabelle, oder
  • da wir ja annehmen, dass es ganz blöd lauft, gehen wir davon aus, dass auch das verratzt wurde und eine 30cm lange Constraint-Bezeichnung vom SQL-Server generiert wurde

---> Diese wurde die ja oben in der Fehlermeldung auch mitgeteilt:
'PKT_TestD8FF7BA46545CD27D'
--> Also wäre ja eine wahrscheinliche Lösung für den ersten Schritt:
ALTER TABLE T_Test DROP CONSTRAINT 'PKT_TestD8FF7BA46545CD27D';  
-- danach die üblichen ALTER TABLE DROP COLUMN-Statements...

Da es nun wirklich keine Empfehlung sein sollte, den Namen der Constraint aus dem Text einer Fehlermeldung herauszu-Copy&Pasten, wäre mein Tipp zur Ermittlung des Namens folgender:
SELECT sk.name AS DerConstraintIhrName
FROM sys.key_constraints AS sk 
Join  sys.tables AS st ON st.object_id = sk.parent_object_id 
WHERE 
sk.type_desc = 'PRIMARY_KEY_CONSTRAINT' and st.name = 'T_Test';  

Grüße
Biber

P.S. Ich verschiebe den Beitrag mal von "Office->Access" nach "Datenbanken".
PCFJKG
PCFJKG 03.04.2009 um 11:05:14 Uhr
Goto Top
Hallo Biber,

zum Vorab: In der Tabelle wurde neben 17 weiteren Spalten die Spalte ZNr als int IDENTITY PRIMARY KEY angelegt. DieseTabelle wird in Verknüpfung mit anderen Tabellen als Source eines Korrekturformulares verwendet. Nach erfolgter Korrektur werden die Daten zurückgeschrieben und die ZNr dabei benötigt. Diese wird mit SELECT (...) INTO neben den erwähnten anderen Spalten und Tabellen in eine Korrekturtabelle geschrieben, die nun dadurch die Definition IDENTITY PRIMARY KEY übernimmt. Ohne es weiter auszuführen, an einer bestimmten Stelle entsteht daraus ein Problem und der geringste Aufwand zur Änderung unserer Software wäre es, die ZNr zu löschen und neu mit ALTER und geänderter Definition wie beschrieben anzufügen; das in meiner Frage veröffentlichte Beispiel CREATE und dann ALTER sollte nur ohne weiteren Ballast das Problem schildern.

Nun meine Ergänzungsfrage:

Kann man den CONSTRAINT-Name \"im Nachhinein\" in der Originaltabelle selbst festlegen (ggf. neue Tabelle und dann die alte kopieren oder inserten ?)

Dann könnte das Problem ein- für allemal mit geringstem Aufwand gelöst werden.

Aber: unabhängig davon:

Wie immer eine konkrete und hilfreiche Antwort, welche die Aufgaben der Fragestellung gelöst hat und
dafür vor allem Anderen VIELEN DANK !

PCFJKG
Biber
Biber 03.04.2009 um 12:25:20 Uhr
Goto Top
Moin PCFJKG,

danke für die Erläuterung der Notwendigkeit. Deiner Lösungssuche...
In der IT kann man/frau wirklich manchmal gar nicht so krumm denken, wie sich manche Prozesse verselbständigen.

zu Deiner Zusatzfrage "Umbenennen der PK_Constraint im Nachhinein"

Ja nee... eigentlich kein Problem.
Die Redmonder haben für derlei Späße eine Stored Procedure mit dabei, die sich sp_rename nennt und mit der Du fast alles (Tabellen, Felder,Indices oder eben auch Constraints) umbenamsen kannst.

[jetzt das "aber"]
Ja hey, bevor Du jetzt eine Suchmaschine befragt nach "mssql sp_rename", erst noch kurz überlegen...

Zum Umbenennen muss ich ja zwei Sachen wissen:
  • den neuen Namen, den das Kind haben soll... und der muss systemweit eindeutig sein -->willst Du Dir das Ausdenken eines "einmaligen" Bezeichners wirklich auch noch aufhalsen? Ich denke, Bestseller wie "Die 5000 beliebtesten Vornamen" zeugen davon, dass die eigene Phantasie oft nicht ausreicht, sich da jeden Tag etwas Peppiges auszudenken.
  • und, noch ärgerlicher, Du brauchst ja auch den bisherigen "alten Namen" der Constraint. zum Umbenamsen.

Was soll's also - wenn Du den alten Namen ohnehin ermitteln musst und dann in Händen hast--> wozu dat Dingen noch umbenennen?? Sobald Du den Namen kennst, kannst Du es doch droppen...

Grüße
Biber
PCFJKG
PCFJKG 03.04.2009 um 14:11:14 Uhr
Goto Top
Hallo Biber,

warum sp_rename nutzen, wenn es im Forum Mitglieder gibt, die "weiter"-denken (?).

Deine Erläuterung leuchtet sofort ein und ich werde ergo Deinen Rat befolgen.

Nun wird es wohl doch noch ein happy weekend. Ich wünsche Dir ein mindestens ebenso schönes Wochenende (das Wetter soll ja wohl endlich mitspielen) und nochmals danke.

Schöne Grüße nach Bremen


PCFJKG