04.12.2007, aktualisiert am 18.07.2008 um 09:51:26 Uhr

19216

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

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: 28.04.2025 um 15:04 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?

Zum Löschen will ich den Enterprise Manager verwenden.

Besser Query Analyser

Kann 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.

Update TabellenName1 Set ROWGID = Null
Go
Update TabellenName2 Set ROWGID = Null
Go
...

und so weiter löscht die Inhalte von Rowgid.

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:

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

Moin Leute,

erst mal vielen Dank für Eure Hinweise.

@Logan000:
Ja, die Spalten sollen komplett gelöscht werden.
Das Programm sieht normalerweise nicht vor, dass es per SQL repliziert wird.
Im Original gibt es also die Spalte "ROWGID" nicht.
Diese wird dann später wieder erzeugt, wenn wir die Replikation erneut einrichten.

Bei der Methode

ALTER TABLE TabellenName1 DROP COLUMN ROWGID...

muss ich ja aber jeden einzelnen Tabellennamen kennen und entsprechend eingeben.

Besser Query Analyser

Might as well... Bin halt nicht sooo fit in SQL. Deswegen wäre ich über den Enterprise Manager gegangen, und wäre dann über die Abfrage gegangen. Da hätte ich dann die entsprechende Syntax eingegeben...
Könnte es sein, dass das aufs Selbe hinausführt...?

@Biber und Logan000:
OK, ich habe nun also den SQL Query Analyzer gestartet.

Meine Datenbank heißt z.B. StammDaten
Darin gibt es 138 Tabellen.
Diese heißen z.B.: Allgemein, Profile, Zubehoer usw...

Im Query Analyzer sind die Tabellen sichtbar als : dbo.A_Allgemein ; dbo.A_Profile usw...

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...?)

Danke noch mal,

Gruß CeMeNt

Moin CeMeNt,

magst Du noch einmal meinen Kommentar von gestern lesen bitte?

Nicht alles, sondern nur die Zeilen zwischen "Moin CeMeNt," und "Grüße"...

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...?)

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

nicht ein + stehen?

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

Hallo Biber,

also Deine Kommentare lese ich immer am liebsten...!

Aber mal im Ernst. Ich habe echt versucht, sowohl den Code von Logan als auch Deinen Code zu entziffern.
Aber leider weiß ich immer noch nicht genau, was ich denn nun im Query Analyzer eingeben muss, um an mein gewünschtes Ergebnis zu kommen.

Kann/soll ich denn einfach das Script, exakt, so wie Du es aufgeschreiben hast, kopieren und in den Analyzer einfügen?
Oder muss noch irgendwo der Datenbankname auftauchen?
Oder muss ich sonst noch weitere Anpassungen machen?

Im Zwischen-den-Zeilen-lesen bin ich was Kommandozeilen-Befehle u.ä. angeht leider echt schlecht...

Danke für alle weiteren Kommentare!

Gruß CeMeNt

Nun habe ich also mal das Script von Biber im QA eingegeben.

SELECT 'ALTER TABLE ' + o.name + ' DROP COLUMN ROWGUID; ' AS MyScript
FROM
sysobjects AS o
INNER JOIN
syscolumns AS c
ON c.id = o.id
WHERE ( o.type = 'U' and c.name = 'ROWGUID' );

liefert folgendes Ergebnis:

MyScript

ALTER TABLE D_Teilserien DROP COLUMN ROWGUID;
ALTER TABLE D_TmpAListe DROP COLUMN ROWGUID;
ALTER TABLE A_MKapa DROP COLUMN ROWGUID;
...
(116 row(s) affected)

Allerdings sind die Spalten "ROUGUID" trotzdem noch vorhanden.
Was hab ich wohl falsch gemacht??

Gruß CeMeNt

Moin CeMeNt,

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

Liest Du Dir bitte noch mal Logan000s Kommentar von heute durch?

Also Logan000s Kommentare lese ich immer am liebsten!

So langsam komme dahinter, was Ihr hier mit mir vorhabt!
Dein Script erzeugt also eine Reihe von Befehlen, wo alle betroffenen Tabellen aufgeführt werden.
Und diese Befehle führe ich anschließend aus!

Ihr sein sooo GUT!

Aber zur Zeit macht mir scheinbar noch meine aktive Replikation einen Strich durch die Rechnung.
Nachdem ich mal eine Zeile ausgeführt habe, kommt folgende Fehlermemldung:

Server: Nachr.-Nr. 4922, Schweregrad 16, Status 1, Zeile 1
ALTER TABLE DROP COLUMN ROWGUID fehlgeschlagen, da DEFAULT CONSTRAINT DF__D_Teilser__rowgu__09C96D33 auf diese Spalte zugreift.

Aber das werde ich bestimmt auch noch irgendwie hinbekommen.

Vielen Dank erst mal, und viele Grüße

CeMeNt

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]

@Biber
Leider kein SQL 7.0 in Reichweite.
Aber Deine Aussagen zu sysobjects.type D, U, RL sind soweit ich mich erinnere richtig.

Ääähhmm, hallo? <vorsichtig anklopf...>

noch jemand da, der mir noch mal weiterhelfen kann?

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.

Irgendwie würd ich ja schon gerne dies Script verwenden, nur fehlt mir eben das Knoff Hoff dazu.

Wäre klasse, wenn Du noch einmal Zeit/Lust dazu hättest.

Gruß CeMeNt
<ganz leise die Tür wieder zu mach...>

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.

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%'  );   

..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)".

Moin Biber,

nun muss ich doch mal wieder diese ollen Kamellen aufwärmen.

Loagan und Du, ihr habt Euch vom halben Jahr ja echt viel Zeit genommen.
Aber ich hatte es bis zum Schluss leider nicht ganz hinbekommen.

Nun habe ich das selbe Problem wieder auf meinem Tisch.
(Unser Programm haben wir immer noch nicht upgedatet, nun soll es aber WIRKLICH losgehen)

Folgendes hat sich an der Situation geändert:

- Wir haben nun einen SBS2003 inkl. SQL-Server 2005

- Meine SQL-Kenntnisse haben sich aber in diesem Bereich nicht wirklich erweitert...

Vielleicht fasse ich einfach noch mal zusammen, was ich will, und was ich bisher gemacht habe:

- Ich habe vier Datenbanken, jeweils mit einem Sack voll Tabellen
- Aus (so gut wie) allen Datenbanken muss ich nun die Spalte "ROWGUID" entfernen

In einer ersten Abfrage gebe ich folgendes Biber-Script ein:

 SELECT 'ALTER TABLE ' + o.name + ' DROP COLUMN ROWGUID; ' AS MyScript  
FROM
sysobjects AS o
INNER JOIN
syscolumns AS c
ON c.id = o.id
WHERE ( o.type = 'U' and c.name = 'ROWGUID' )  

Das Liefert mir 109 Zeilen, die alle ungefähr so aussehen:

ALTER TABLE S_BAufloesung DROP COLUMN ROWGUID; 
ALTER TABLE S_PreisFind DROP COLUMN ROWGUID; 
ALTER TABLE Preisgruppen DROP COLUMN ROWGUID; 
...
...

Gebe ich nun z.B. die erste Zeile in die Abfrage ein, so erscheint folgende Fehlermeldung:

Meldung 5074, Ebene 16, Status 1, Zeile 1Das Objekt-Objekt 'DF__S_BAufloe__rowgu__7226EDCC' ist vom Spalte-Objekt 'ROWGUID' abhängig.Meldung 5074, Ebene 16, Status 1, Zeile 1Das Index-Objekt 'index_1250103494' ist vom Spalte-Objekt 'ROWGUID' abhängig.Meldung 4922, Ebene 16, Status 9, Zeile 1Fehler bei ALTER TABLE DROP COLUMN ROWGUID, da mindestens ein Objekt auf diese Spalte zugreift.

Tja, und sind sie wieder, meine drei Probleme:
1.) S
2.) Q
3.) L

Vielleicht hast Du ja noch mal Zeit und Lust, Dir diese Sache anzusehen?

Wäre echt super!

Danke schon mal, und viele Grüße

CeMeNt

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

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 Biber,

erst mal Danke, dass Du Dich der Sache noch mal annimmst!

Ich hab mir den gesamten Threat nun schon 20 mal durchgelesen.
Aber irgendwie scheint bei mir eine Schnittstelle defekt zu sein.
Die Augen erkennen zwar jeden einzelnen Buchstaben, aber im Hirn kommt nur ein Rauschen an...

liegen denn auf den Tabellen noch Indexe/Indizes, die das Feld >ROWGUID beinhalten?

Ich versuche mich mal an diese Frage heran.
Also, das Programm selbst verwendet die Spalte ROGUID gar nicht.
Sie ist für die Replikation der DB zwischen unseren zwei Standorten da.
Eventuell liegt es an einer aktiven Replikation?

Aber eigentlich kann das auch nicht sein. Ich teste das Löschen natürlich nicht an meiner original DB, sondern an einer 1:1 Kopie.

Wie kann ich wohl feststellen, ob ein Index das Feld ROWGUID enthalten?

haben denn die Tabellen inzwischen wieder "richtige" PKs in Unique-
Index-Felder?

Oh, waren die denn weg?
Was waren die PKs gleich noch mal?

wenn die Tabellen wieder einen echten PK haben, der gewährleistet,
dass keine Duplikate bei unseren Spielereien INSERTed werden können, > dann

Ahh, hier erkenne ich das Wort "Duplikate".
Kann es sein, dass Du hier von "Doppelten Datensätzen" sprichst?
Es könnte durchaus sein, dass in der einen oder anderen Tabelle doppelte Datensätze vorhanden sind.
Könnte das das Problem sein?

Die CONSTRAINTs Droppen - siehe das zweite "ALTER"-Skript oben.
nach den Constraints die "toten" ROWGUID-Felder mit dem ersten Skript > wegpusten.

Also hier wirds echt haarig!
Damit kann ich nun leider echt gar nichts anfangen.

Tja, Biber, sieht so aus, als ob das hier noch eine Weile dauern könnte.
Vielleicht sagst Du ja noch mal Bescheid, ob Du die Nerven hast, mich in der Sache noch ein wenig zu supporten.

Ich könnt ja verstehen, wenn Du den Thread lieber droppen würdest, und Dir dafür lieber ein paar ALT(ER)-Bier in den "toten" Körper pusten würdest.

Erst mal einen schönen Abend noch.

Gruß CeMeNt

Moin moin.

Ich bins noch mal.

Ich hab mir die Fehlermeldung noch ein paar mal durchgelesen.
Da heist es ja:

Das Objekt-Objekt 'DFS_BAufloerowgu__7226EDCC' ist vom Spalte-Objekt 'ROWGUID' abhängig.
und
Das Index-Objekt 'index_1250103494' ist vom Spalte-Objekt 'ROWGUID' abhängig

Nun ist natürlich die große Frage:
Wo finde ich das Objekt-Objekt und das Index-Objekt?

Das gehört doch sicherlich alles zu unserer Replikation.
Die würde ich dann am Ende halt noch mal kopmlett neu einrichten.
Also könnte meiner Meinung nach alles gelöscht werden, was mit dieser ROWGUID zu tun hat.

Oder hab ich da wieder mal zu kurz gedacht??

Gruß CeMeNt

<edit>
Ich hab jetzt noch mal den zweiten Biber-Code eingefügt, und hab ja langsam die Vermutung, dass Du genau das machen wolltest.
Allerdings scheint es mit der Syntax noch ein kleines Problem zu geben.

Der Code:

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%'  )  

erzeugt folgende Fehlermeldung

Meldung 156, Ebene 15, Status 1, Zeile 3
Falsche Syntax in der Nähe des 'AS'-Schlüsselwortes.  

Also ist evtl. der Ausdruck "DROP CONSTRAINT" nicht ganz korrekt?
</edit>

Gruß CeMeNt

Moin

Der Fehler stekt in Zeile 1.

Besser so:

SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT  ' + c.name + ';'  AS MyScript   
...

Wollt ihr eigentlich die Replikation wieder aufnehmen, wenn Ihr die Datenbanken Migriert habt?

Gruß L.

Hallo Logan,

super, dass Du Dich hier auch noch mal einklinkst!!

Also der neue Biber/Logan-Code bringt zwar nun keine Fehlermeldung mehr,
allerdings scheint er nichts anzustellen:

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%'  )  

Meldung:

(0 Zeile(n) betroffen)

Wollt ihr eigentlich die Replikation wieder aufnehmen, wenn Ihr die Datenbanken Migriert habt?

Ja, anschließend wollen wir die Replikation wieder anwerfen.
Das hatten wir aber vor einiger Zeit schon mal mit einer anderen Test-DB ausprobiert.
Es sah auch so aus, als ob wir das hinbekommen hätten.

Macht das die Sache komplizierter?

Übrigens:
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??

Gruß CeMeNt

Moin

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.

Ok, ich fasse noch mal zusammen:

- Aktuell läuft unser Programm auf einer SQL7.0 Datenbank
- Diese wird täglich mit unserem Produktionsstandort repliziert
- Produktion = Verleger, Verwaltung (ich) = Abonnent

- nun wollen wir unser Programm updaten.
- damit das Update aber eingespielt werden kann, müssen alle Spalten, die was mit der Replikation zu tun haben, zunächst gelöscht werden

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)

Wo ist das Problem?
- Manuelles Löschen der Spalte "ROWGUID" ist ohne Fehlermeldung möglich (aber mit sehr hohem zeitlichen Aufwand verbunden)
- Löschen per Skript erzeugt diverse Fehlermeldungen, da das Skript scheinbar noch irgendwelche Verknüpfungen zu dieser Spalte feststellt.

Zum M$-Artikel:
- Für die neue 2005er Datenbank habe ich ja noch nichts an Replikation eingerichtet.
- Es gibt also noch keinen Verleger und Abonnenten

- Die Replikation für die 7.0er Datenbank kann ich natürlich noch nicht entfernen, da dies ja noch unser produktives System ist, auf dem täglich gearbeitet wird.

- auf diesem neuen Server ist keine Replikation eingerichtet?

Nun ja, sagen wir mal jein.
Also es ist keine "echte" Replikation eingerichtet.
Wie gesagt, wir hatten die Replikation schon mal testweise mit einer Test-Datenbank eingerichtet.
Ich stelle aber gerade fest, dass diese wohl nicht aktiv ist oder nicht (mehr?) funktioniert.
Also alles, was auf dem neuen Server an Replikation vorhanden ist, ist nicht produktiv wichtig

Gruß CeMeNt

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.

Habe den Befehl ausgeführt:

sp_removedbreplication ' ha_st40 '

Meldungen:
Befehl(e) wurde(n) erfolgreich abgeschlossen.

Habe danach dann noch mal den Biber-Code sowie den Biber/Logan-Code ausgeführt.
Aber am Ergebnis hat sich leider nichts geändert.

Laut der MS-Dokumentation, hört sich

Systemprozedur, die gespeichert wird, zu dem Löschen alle Replikationsobjekte

so an, als ob damit wirklich ALLE Objekte gelöscht werden würden.

Ich hab trotzdem noch mal das versucht:

sp droppullsubscription: um ein Abonnement in der aktuellen Datenbank des Abonnenten zu
löschen, können Sie die sp droppullsubscription Systemprozedur verwenden, die gespeichert
wird. Sie müssen die gespeicherte Prozedur in der Pullabonnementdatenbank auf dem
Abonnent ausführen.

Hab folgendes eingegeben:

sp droppullsubscription ' ha_st40'

Ergab aber die Meldung:
Meldung 102, Ebene 15, Status 1, Zeile 1Falsche Syntax in der Nähe von 'ha_st40'.

Hab ich irgendwo irgendwas grundlegend falsch gemacht?
Oder scheint das einfach nicht zu funktionieren??

Hast Du noch Lust?
Ich langsam nicht mehr...

Gruß CeMeNt

HAllo CeMeNt

Zuviel des Guten.
Ich hätte erwartet das

sp_removedbreplication 'ha_st40'

ausreicht.

Gruß L.

Kanns Dir nicht verübeln.
Danke trotzdem für Deine Mühen.

Vielleicht hat ja der Biber noch eine zündende Idee.

Mal sehen, ob er sich noch mal hier einklinkt....

Bis denne,

Gruß CeMeNt

P.S.:
Dann bleibt wohl nur Plan-B (löschen per Hand...)

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:

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

Hallo Leute,

also das verstehe ich nun überhaupt nicht mehr...

Als ich gerade eben (schon fast aus Gewohnheit) den Biber-Code eingegeben habe, und danach das Ergebnis daraus in eine neue Abfrage eingefügt habe, ließen sich die Spalten plötzlich löschen!!!

Wer weiß, wahrscheinlich hat einer der oben genannten Befehle doch funktioniert.
Und vielleicht hat es etwas gedauert, bis die Vernküpfungen zur (eigentlich nicht vorhandenen) Replikation gekappt wurden.

Wie auch immer, meine Tabellen sind seit heute morgen "ROWGUID"-frei!!!

Vielen vielen Dank, Jungs!

Ohne Euch würde ich wohl hier am Maus-Arm zugrunden gehen...!

Bis zu nächsten mal...

Gruß CeMeNt

gelöstFrage Datenbanken Entwicklung

Mehr von CeMeNt

Andere Namen für -Admins-CeMeNt - 34 Kommentare

Daten bearbeiten mit SQL-Server Management Studio 2008CeMeNt - 9 Kommentare

Excel - Bereich durchsuchenCeMeNt - 6 Kommentare

E-Postbrief?CeMeNt - 7 Kommentare

Heiß diskutiert