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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 112982
Url: https://administrator.de/contentid/112982
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
6 Kommentare
Neuester Kommentar
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.
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.
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:
---> Diese wurde die ja oben in der Fehlermeldung auch mitgeteilt:
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:
Grüße
Biber
P.S. Ich verschiebe den Beitrag mal von "Office->Access" nach "Datenbanken".
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".
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:
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
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