SQL Server 7.0 - Löschen von Spalten
Moin Leute,
wir haben hier ein Programm im Einsatz, welches noch auf MS SQL-Server 7.0 läuft.
Da wir zwei Standorte haben, werden die entsprechenden Datenbanken regelmäßig per SQL repliziert.
Nun lassen sich aus dem Programm einige Funktionen nicht mehr starten.
Deswegen will ich die Datenbanken aus einem Backup wiederherstellen.
Dazu müssen allerdings aus den einzelnen Tabellen die Spalten gelöscht werden, die für die Replikation notwendig sind (ROWGID).
Die Anwendung verwendet insgesamt fünf SQL-Datenbanken, jede mit ca. 150 einzelnen Tabellen.
Und in jeder dieser Tabelle muss die Spalte "ROWGID" gelöscht werden.
Zum Löschen will ich den Enterprise Manager verwenden.
Nun meine Frage:
Kann man eine Spalte per Skript löschen?
Kann man evtl. sogar ein Skript schreiben, was diese Spalte aus allen Tabellen innerhalb einer Datenbank löscht?
Falls ja, wäre es super, wenn mir jemand das Skript hier aufschreiben könnte, wie es dann auch im Enterprise Manager eingegeben werden muss.
Danke für alle Tipps,
Gruß CeMeNt
wir haben hier ein Programm im Einsatz, welches noch auf MS SQL-Server 7.0 läuft.
Da wir zwei Standorte haben, werden die entsprechenden Datenbanken regelmäßig per SQL repliziert.
Nun lassen sich aus dem Programm einige Funktionen nicht mehr starten.
Deswegen will ich die Datenbanken aus einem Backup wiederherstellen.
Dazu müssen allerdings aus den einzelnen Tabellen die Spalten gelöscht werden, die für die Replikation notwendig sind (ROWGID).
Die Anwendung verwendet insgesamt fünf SQL-Datenbanken, jede mit ca. 150 einzelnen Tabellen.
Und in jeder dieser Tabelle muss die Spalte "ROWGID" gelöscht werden.
Zum Löschen will ich den Enterprise Manager verwenden.
Nun meine Frage:
Kann man eine Spalte per Skript löschen?
Kann man evtl. sogar ein Skript schreiben, was diese Spalte aus allen Tabellen innerhalb einer Datenbank löscht?
Falls ja, wäre es super, wenn mir jemand das Skript hier aufschreiben könnte, wie es dann auch im Enterprise Manager eingegeben werden muss.
Danke für alle Tipps,
Gruß CeMeNt
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 75184
Url: https://administrator.de/forum/sql-server-7-0-loeschen-von-spalten-75184.html
Ausgedruckt am: 06.07.2025 um 12:07 Uhr
28 Kommentare
Neuester Kommentar
Dazu müssen allerdings aus den einzelnen Tabellen die Spalten gelöscht
werden, die für die Replikation notwendig sind (ROWGID).
Möchtest Du Die Spalte aus der Tabelle entfernen oder den Inhalt diser Spalte löschen?werden, die für die Replikation notwendig sind (ROWGID).
Zum Löschen will ich den Enterprise Manager verwenden.
Besser Query AnalyserKann man eine Spalte per Skript löschen?
Ja.Kann man evtl. sogar ein Skript schreiben, was diese Spalte aus allen Tabellen innerhalb
einer Datenbank löscht?
Ja.einer Datenbank löscht?
Update TabellenName1 Set ROWGID = Null
Go
Update TabellenName2 Set ROWGID = Null
Go
...
Und so entfernst du die spalten aus den tabellen
ALTER TABLE TabellenName1 DROP COLUMN ROWGID
GO
ALTER TABLE TabellenName2 DROP COLUMN ROWGID
GO
...
Moin CeMeNt,
...und das Script zum Spalten-DROPpen lässt Du Dir am Besten schreiben:
Das liefert für alle (User-)Tabellen, also sysobjects.type="U" jeweils eine Zeile in der von Logan000 geschriebenen Form. Natürlich nur, wenn die Tabelle eine Spalte mit dem Namen "ROWGID" enthält.
Ich würde aber zumindest nochmal prüfen, ob/welche anderen sysobjects-Zeilen auch eine Spalte "ROWGID" enthalten.
Grüße
Biber
...und das Script zum Spalten-DROPpen lässt Du Dir am Besten schreiben:
SELECT 'ALTER TABLE ' || o.name || ' DROP COLUMN ROWGID; ' AS MyScript
FROM
sysobjects AS o
INNER JOIN
syscolumns AS c
ON c.id = o.id
WHERE ( o.type = 'U' and c.name = 'ROWGID' );
Das liefert für alle (User-)Tabellen, also sysobjects.type="U" jeweils eine Zeile in der von Logan000 geschriebenen Form. Natürlich nur, wenn die Tabelle eine Spalte mit dem Namen "ROWGID" enthält.
Ich würde aber zumindest nochmal prüfen, ob/welche anderen sysobjects-Zeilen auch eine Spalte "ROWGID" enthalten.
Grüße
Biber
Könnt Ihr mir vielleicht noch einmal die exakte Syntax aufschreiben, die ich im
Analyzer eingeben muss, um die Spalte "ROWGID" aus den Tabellen komplett
zu entfernen?
(Am liebsten so, dass ich nicht alle 138 Tabellen-Namen einzeln eingeben muss? Wenn
dass denn geht...?)
Analyzer eingeben muss, um die Spalte "ROWGID" aus den Tabellen komplett
zu entfernen?
(Am liebsten so, dass ich nicht alle 138 Tabellen-Namen einzeln eingeben muss? Wenn
dass denn geht...?)
Das Skript von Biber liefert als Ergebis ein Skript zum löschen der Spalte Rowid in allen denen Tabellen.
Führe es im QA aus und kopiere das Ergebis in ein neues Abfragefenster. Ausführen. fertig.
@Biber
SELECT 'ALTER TABLE ' || o.name || ' DROP COLUMN ROWGID; ' AS MyScript
Moin Logan000,
Hm, ich hab natürlich keinen M$-SQLServer hier stehen zum Testen.
So alt und bieder fühl ich mich ja doch noch nicht, dass ich etwas sooo Altbackenes nehme.
Ich dachte, mit dem Standard-SQL-Concat-Operator wäre ich auf der sicheren Seite.
Aber wenn sich der Query-Analyzer da mehr an Access/VB-Syntax anlehnt, dann meinetwegen zum Verketten von Strings auch " + " oder " & ".
Grüße
Biber
Moin CeMeNt,
Liest Du Dir bitte noch mal Logan000s Kommentar von heute durch?
Nicht alles, nur von:
Breit grinsend (aber nichts böse meinend)
Biber
Was hab ich wohl falsch gemacht??
Du hast alles richtig gemacht..<tätschel>..Liest Du Dir bitte noch mal Logan000s Kommentar von heute durch?
Nicht alles, nur von:
"Führe es im QA aus und kopiere das Ergebnis in ein neues Abfragefenster. "
bis zu ..."Ausführen. fertig."
Breit grinsend (aber nichts böse meinend)
Biber
Moin CeMeNt,
das meinte ich in meinem ersten Kommentar - wir sollten mal schauen, in welchen anderen sysobjects-Zeilen noch diese ROWGUID enthalten ist.
Im Prinzip müssen wir also noch ein zweites Script vorwegschalten, das VOR dem Droppen der Spalten ein "ALTER TABLE xxxx DROP CONSTRAINT DFD_Teilserrowgu__09C96D33 ... bla" macht.
Das Basteln des Skripts ist genau das gleiche Muster wie oben, nur der Typ (o.type) ist nicht mehr "U" wie UserInnen-Tabelle, sondern "D" wie Bratkardoffel bzw wie "[Default-]Constraint."
@Logan000:
Falls Du gerade an so einer Büchse sitzen solltest, könntest Du mal bitte verifizieren?
Ich kann es momentan nur aus dem zusammenphantasieren was Alk und Alzheimer noch nicht zerstört haben...
Danke.
Grüße
Biber
[Edit] Ein weiterer Kandidat für zu droppende Objecte könnten die o.type="RF" (Replication filter stored procedures) sein, ist mir beim Essen eingefallen. [/Edit]
das meinte ich in meinem ersten Kommentar - wir sollten mal schauen, in welchen anderen sysobjects-Zeilen noch diese ROWGUID enthalten ist.
Im Prinzip müssen wir also noch ein zweites Script vorwegschalten, das VOR dem Droppen der Spalten ein "ALTER TABLE xxxx DROP CONSTRAINT DFD_Teilserrowgu__09C96D33 ... bla" macht.
Das Basteln des Skripts ist genau das gleiche Muster wie oben, nur der Typ (o.type) ist nicht mehr "U" wie UserInnen-Tabelle, sondern "D" wie Bratkardoffel bzw wie "[Default-]Constraint."
@Logan000:
Falls Du gerade an so einer Büchse sitzen solltest, könntest Du mal bitte verifizieren?
Ich kann es momentan nur aus dem zusammenphantasieren was Alk und Alzheimer noch nicht zerstört haben...
Danke.
Grüße
Biber
[Edit] Ein weiterer Kandidat für zu droppende Objecte könnten die o.type="RF" (Replication filter stored procedures) sein, ist mir beim Essen eingefallen. [/Edit]
@Biber
Leider kein SQL 7.0 in Reichweite.
Aber Deine Aussagen zu sysobjects.type D, U, RL sind soweit ich mich erinnere richtig.
Leider kein SQL 7.0 in Reichweite.
Aber Deine Aussagen zu sysobjects.type D, U, RL sind soweit ich mich erinnere richtig.
Moin CeMeNt,
kannst ruhig reinkommen...
Also, was wir inzwischen wissen (und wo Du jetzt weiter testen musst, weil weder Logan000 noch ich einen SQLServer 7.0 unterm Schreibtisch stehen haben):
Bevor wir die Replikations-Hilfsspalten selbst löschen können, müssen wir die CONSTRAINTS (neudeutsch für Sicherungshaken) entfernen.
Diese hier...
Server: Nachr.-Nr. 4922, Schweregrad 16, Status 1, Zeile 1
ALTER TABLE DROP COLUMN ROWGUID fehlgeschlagen, da DEFAULT CONSTRAINT DFD_Teilserrowgu__09C96D33
Diese können wir alle 143 (bei 143 Tabellen) auch wiederfinden mit einem leicht variierten Scriptchen.
..so in etwa [UNGETESTET!!]
Denn der Name in syscolumns (c.name) scheint ja aus "DF" + Teil-Tabellenname/o.name+ "rowgu_Lfdnr" zusammengebastelt werden.
Vielleicht stößt ja noch jemand mit so einer Drecksgurk^H^H mit so einem frei skalierbaren, wohl dokumentierten M$SQLServer 7.0 dazu, der ein bisschen mittesten kann.
Grüße
Biber
[Edit] WHERE- clause angepasst. Im DF-Namen scheinen die ersten 9 Zeichen des Tabellennamens (bei "D_Teilserien" z.B. " D_Teilser") zu stecken... also "LEFT(name ,9)".
kannst ruhig reinkommen...
Also, was wir inzwischen wissen (und wo Du jetzt weiter testen musst, weil weder Logan000 noch ich einen SQLServer 7.0 unterm Schreibtisch stehen haben):
Bevor wir die Replikations-Hilfsspalten selbst löschen können, müssen wir die CONSTRAINTS (neudeutsch für Sicherungshaken) entfernen.
Diese hier...
Server: Nachr.-Nr. 4922, Schweregrad 16, Status 1, Zeile 1
ALTER TABLE DROP COLUMN ROWGUID fehlgeschlagen, da DEFAULT CONSTRAINT DFD_Teilserrowgu__09C96D33
Diese können wir alle 143 (bei 143 Tabellen) auch wiederfinden mit einem leicht variierten Scriptchen.
SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT '
+ c.name; ' AS MyScript
FROM
sysobjects AS o
INNER JOIN
syscolumns AS c
ON c.id = o.id
WHERE ( o.type = 'D' and c.name LIKE 'DF' + Left ( o.name , 9) +'row%' );
Denn der Name in syscolumns (c.name) scheint ja aus "DF" + Teil-Tabellenname/o.name+ "rowgu_Lfdnr" zusammengebastelt werden.
Vielleicht stößt ja noch jemand mit so einer Drecksgurk^H^H mit so einem frei skalierbaren, wohl dokumentierten M$SQLServer 7.0 dazu, der ein bisschen mittesten kann.
Grüße
Biber
[Edit] WHERE- clause angepasst. Im DF-Namen scheinen die ersten 9 Zeichen des Tabellennamens (bei "D_Teilserien" z.B. " D_Teilser") zu stecken... also "LEFT(name ,9)".
Moin CeMeNt,
Bitte lies auch noch mal die Kommentare von unserer ersten Runde nach - dass sich die Spalten nicht löschen/droppen lassen, weil die ja PK oder PK-Ersatz verwendet werden... das hatte wir schon herausgefunden.
Wir waren oben - nein, ich war oben zu sehr mit der Holzhammermethode herangegangen: "Hey, überflüsssige Spalten - schmeissen wir weg und fertig."
Im Moment sind sie aber noch gar nicht überflüssig, da sie als eindeutige Schlüssel verwendet werden - diesen Status mussen wir zuerst aufheben.
--> deshalb: erst gucken, dann drauflos. Fragen
Grüße
Biber
Bitte lies auch noch mal die Kommentare von unserer ersten Runde nach - dass sich die Spalten nicht löschen/droppen lassen, weil die ja PK oder PK-Ersatz verwendet werden... das hatte wir schon herausgefunden.
Wir waren oben - nein, ich war oben zu sehr mit der Holzhammermethode herangegangen: "Hey, überflüsssige Spalten - schmeissen wir weg und fertig."
Im Moment sind sie aber noch gar nicht überflüssig, da sie als eindeutige Schlüssel verwendet werden - diesen Status mussen wir zuerst aufheben.
--> deshalb: erst gucken, dann drauflos. Fragen
- liegen denn auf den Tabellen noch Indexe/Indizes, die das Feld ROWGUID beinhalten?
- haben denn die Tabellen inzwischen wieder "richtige" PKs in Unique-Index-Felder?
- wenn die Tabellen wieder einen echten PK haben, der gewährleistet, dass keine Duplikate bei unseren Spielereien INSERTed werden können, dann
- Die CONSTRAINTs Droppen - siehe das zweite "ALTER"-Skript oben.
- nach den Constraints die "toten" ROWGUID-Felder mit dem ersten Skript wegpusten.
Grüße
Biber
Moin
Auf jeden Fall soltest Du deine Recovery Strategien überprüfen.
Da das herumwühlen in den systemtabellen nicht sehr erfolgreich war,
habe ich noch ein paar Fragen zur ausgangssituation.
Du hast eine Sicherung einer SQL 7.0 Replikations DB
- auf einem SQL 2005 zurückgesichert? oder auf einem 7.0?
- auf diesem neuen Server ist keine Replikation eingerichtet?
Ich habe follgenden Artikel bei M$ gefunden. Danach macht die Procedur
sp_removedbreplication '<Datenbanknam>'
genau das was wir hier in "Handarbeit" probieren.
Gruß L.
Wenn ich über "Tabelle entwerfen" gehe, dann kann ich die Spalte manuell löschen. Das wäre im übrigen auch mein Plan-B, alle Tabellen von Hand bereinigen. Oder wäre das keine gute Idee, weil ich dann irgendwas ganz kaputt mache??
Ob per Skript oder von Hand ist nun echt egal.Macht das die Sache komplizierter?
Nun, wie Du siehst macht es das zurücksichern etwas komplizierter.Auf jeden Fall soltest Du deine Recovery Strategien überprüfen.
Da das herumwühlen in den systemtabellen nicht sehr erfolgreich war,
habe ich noch ein paar Fragen zur ausgangssituation.
Du hast eine Sicherung einer SQL 7.0 Replikations DB
- auf einem SQL 2005 zurückgesichert? oder auf einem 7.0?
- auf diesem neuen Server ist keine Replikation eingerichtet?
Ich habe follgenden Artikel bei M$ gefunden. Danach macht die Procedur
sp_removedbreplication '<Datenbanknam>'
genau das was wir hier in "Handarbeit" probieren.
Gruß L.
Was habe ich zuletzt gemacht?
- Habe auf dem SQL2005 eine neue (leere) 2005er Datenbank angelegt- Danach hab ich aus dem Backup meiner 7.0er DB eine Wiederherstellung auf der 2005er gemacht
- Die neue DB ist also nun inhaltlich identisch mit der alten.
- Für die neue DB ist noch nichts an Replikation eingerichtet worden (macht ja jetzt auch noch keinen Sinn)
D.h.: Du hast eine DB (inkusive Replikationsschrott) für die noch keine neue Replikation eingrichtet ist. Auf einem SQL 2k5 liegen.
Start auszug [
• sp removedbreplication: Sie können die sp removedbreplication Systemprozedur, die gespeichert wird, zu dem Löschen alle Replikationsobjekte, ohne die Daten auf dem Verteiler zu aktualisieren, aus einer Datenbank verwenden. Auf Publikationsverleger für die Datenbank oder dem Abonnent für die Abonnementdatenbank müssen Sie die gespeicherte Prozedur ausführen. Ist der folgenden Syntax für diese gespeicherte Prozedur:
sp_removedbreplication '<Datenbanknam>'
Edne Auszug ]
So wie ich das verstehe, entfernt diese Proc alle Replikations Objekte in der Datenbank.
Gruß L.
Moin CeMeNt und Logan000,
ich lese ja durchaus noch mit... aber hatte nicht das Gefühl, dass Logans Alternative scheitern könnte...
Deshalb erst noch mal die Rückfragen @CeMeNt:
Denn die Fehlermeldung mit "in Zeile 1" deutet doch eher darauf hin, dass ...
Und: die erste StoredProcedure, die "Erfolg" gemeldet hatte.... hat die den nix verändert an den Tabellen? Sind ROWGUIDs und Constraints denn noch da?
Plan B wäre für mich (bevor ich es in x tabellen manuell versuche) dann doch erstmal die angegebenen STPs zu lesen...
Die können ja nun -wie auch Logan schrieb- nix anderes versuchen als ich mit dem blind geschossenen ALTER-Skriptchen.
Und dann dieses Vorgehen bestmöglich nachzukaspern.
Grüße
Biber
ich lese ja durchaus noch mit... aber hatte nicht das Gefühl, dass Logans Alternative scheitern könnte...
Deshalb erst noch mal die Rückfragen @CeMeNt:
sp droppullsubscription ' ha_st40'
??? Das Leerzeichen zwischen "sp" und "dropWhatever" ist nur ein Tippfehler hier?Denn die Fehlermeldung mit "in Zeile 1" deutet doch eher darauf hin, dass ...
Und: die erste StoredProcedure, die "Erfolg" gemeldet hatte.... hat die den nix verändert an den Tabellen? Sind ROWGUIDs und Constraints denn noch da?
Plan B wäre für mich (bevor ich es in x tabellen manuell versuche) dann doch erstmal die angegebenen STPs zu lesen...
Die können ja nun -wie auch Logan schrieb- nix anderes versuchen als ich mit dem blind geschossenen ALTER-Skriptchen.
Und dann dieses Vorgehen bestmöglich nachzukaspern.
Grüße
Biber