Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

SQL Server 7.0 - Löschen von Spalten

Frage Entwicklung Datenbanken

Mitglied: CeMeNt

CeMeNt (Level 2) - Jetzt verbinden

04.12.2007, aktualisiert 18.07.2008, 14328 Aufrufe, 28 Kommentare

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
28 Antworten
Mitglied: Logan000
04.12.2007 um 17:38 Uhr
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.

01.
Update TabellenName1 Set ROWGID = Null 
02.
Go 
03.
Update TabellenName2 Set ROWGID = Null 
04.
Go 
05.
...
und so weiter löscht die Inhalte von Rowgid.

Und so entfernst du die spalten aus den tabellen
01.
ALTER TABLE TabellenName1  DROP COLUMN ROWGID  
02.
GO 
03.
ALTER TABLE TabellenName2  DROP COLUMN ROWGID  
04.
GO 
05.
...
Bitte warten ..
Mitglied: Biber
04.12.2007 um 18:50 Uhr
Moin CeMeNt,

...und das Script zum Spalten-DROPpen lässt Du Dir am Besten schreiben:

01.
SELECT     'ALTER TABLE ' || o.name || ' DROP COLUMN ROWGID; ' AS MyScript  
02.
FROM         
03.
 sysobjects AS o  
04.
INNER JOIN 
05.
 syscolumns AS c  
06.
  ON   c.id = o.id  
07.
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
Bitte warten ..
Mitglied: CeMeNt
05.12.2007 um 08:11 Uhr
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
Bitte warten ..
Mitglied: Biber
05.12.2007 um 08:48 Uhr
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
Bitte warten ..
Mitglied: Logan000
05.12.2007 um 08:57 Uhr
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
Solte für || in der Zeile
01.
SELECT     'ALTER TABLE ' || o.name || ' DROP COLUMN ROWGID; ' AS MyScript 
nicht ein + stehen?
Bitte warten ..
Mitglied: Biber
05.12.2007 um 09:14 Uhr
Moin Logan000,

Solte für || in der Zeile...

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
Bitte warten ..
Mitglied: CeMeNt
05.12.2007 um 09:14 Uhr
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
Bitte warten ..
Mitglied: CeMeNt
05.12.2007 um 09:38 Uhr
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
Bitte warten ..
Mitglied: Biber
05.12.2007 um 10:01 Uhr
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
Bitte warten ..
Mitglied: CeMeNt
05.12.2007 um 11:37 Uhr
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
Bitte warten ..
Mitglied: Biber
05.12.2007 um 13:04 Uhr
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]
Bitte warten ..
Mitglied: Logan000
06.12.2007 um 08:54 Uhr
@Biber
Leider kein SQL 7.0 in Reichweite.
Aber Deine Aussagen zu sysobjects.type D, U, RL sind soweit ich mich erinnere richtig.
Bitte warten ..
Mitglied: CeMeNt
07.12.2007 um 13:21 Uhr
Äää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.

Also, Biber, Du hattest ja mit Deinem ersten Versuch schon ziemlich ins Schwarze getroffen (mal abgesehen von || oder +). Ich könnte mir vorstellen, dass Dir das bestimmt noch einmal gelingen könnte...

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

Gruß CeMeNt
<ganz leise die Tür wieder zu mach...>
Bitte warten ..
Mitglied: Biber
07.12.2007 um 13:48 Uhr
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.
01.
SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT  ' 
02.
       + c.name; ' AS MyScript  
03.
FROM  
04.
sysobjects AS o  
05.
INNER JOIN 
06.
syscolumns AS c  
07.
ON c.id = o.id  
08.
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)".
Bitte warten ..
Mitglied: CeMeNt
16.07.2008 um 17:30 Uhr
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:

01.
 SELECT 'ALTER TABLE ' + o.name + ' DROP COLUMN ROWGUID; ' AS MyScript 
02.
FROM 
03.
sysobjects AS o 
04.
INNER JOIN 
05.
syscolumns AS c 
06.
ON c.id = o.id 
07.
WHERE ( o.type = 'U' and c.name = 'ROWGUID' )
Das Liefert mir 109 Zeilen, die alle ungefähr so aussehen:
01.
ALTER TABLE S_BAufloesung DROP COLUMN ROWGUID;  
02.
ALTER TABLE S_PreisFind DROP COLUMN ROWGUID;  
03.
ALTER TABLE Preisgruppen DROP COLUMN ROWGUID;  
04.
... 
05.
...
Gebe ich nun z.B. die erste Zeile in die Abfrage ein, so erscheint folgende Fehlermeldung:

Meldung 5074, Ebene 16, Status 1, Zeile 1
Das Objekt-Objekt 'DF__S_BAufloe__rowgu__7226EDCC' ist vom Spalte-Objekt 'ROWGUID' abhängig.
Meldung 5074, Ebene 16, Status 1, Zeile 1
Das Index-Objekt 'index_1250103494' ist vom Spalte-Objekt 'ROWGUID' abhängig.
Meldung 4922, Ebene 16, Status 9, Zeile 1
Fehler 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
Bitte warten ..
Mitglied: Biber
16.07.2008 um 19:28 Uhr
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
Bitte warten ..
Mitglied: CeMeNt
16.07.2008 um 20:33 Uhr
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
Bitte warten ..
Mitglied: CeMeNt
17.07.2008 um 09:02 Uhr
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:
01.
SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT  ' + c.name;  AS MyScript  
02.
FROM  
03.
sysobjects AS o  
04.
INNER JOIN 
05.
syscolumns AS c  
06.
ON c.id = o.id  
07.
WHERE ( o.type = 'D' and c.name LIKE 'DF' + Left ( o.name , 9) +'row%'  )
erzeugt folgende Fehlermeldung

01.
Meldung 156, Ebene 15, Status 1, Zeile 3 
02.
Falsche Syntax in der Nähe des 'AS'-Schlüsselwortes.
Also ist evtl. der Ausdruck "DROP CONSTRAINT" nicht ganz korrekt?
</edit>

Gruß CeMeNt
Bitte warten ..
Mitglied: Logan000
17.07.2008 um 09:26 Uhr
Moin

Der Fehler stekt in Zeile 1.

Besser so:
01.
SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT  ' + c.name + ';'  AS MyScript  
02.
...
Wollt ihr eigentlich die Replikation wieder aufnehmen, wenn Ihr die Datenbanken Migriert habt?

Gruß L.
Bitte warten ..
Mitglied: CeMeNt
17.07.2008 um 09:50 Uhr
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:

01.
SELECT 'ALTER TABLE ' + o.name + ' DROP CONSTRAINT  ' + c.name + ';'  AS MyScript   
02.
FROM  
03.
sysobjects AS o  
04.
INNER JOIN 
05.
syscolumns AS c  
06.
ON c.id = o.id  
07.
WHERE ( o.type = 'D' and c.name LIKE 'DF' + Left ( o.name , 9) +'row%'  )
Meldung:
01.
(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
Bitte warten ..
Mitglied: Logan000
17.07.2008 um 11:02 Uhr
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.
Bitte warten ..
Mitglied: CeMeNt
17.07.2008 um 11:55 Uhr
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
Bitte warten ..
Mitglied: Logan000
17.07.2008 um 12:37 Uhr
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.
Bitte warten ..
Mitglied: CeMeNt
17.07.2008 um 13:13 Uhr
Habe den Befehl ausgeführt:

01.
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:
01.
sp droppullsubscription ' ha_st40'
Ergab aber die Meldung:
Meldung 102, Ebene 15, Status 1, Zeile 1
Falsche 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
Bitte warten ..
Mitglied: Logan000
17.07.2008 um 15:43 Uhr
HAllo CeMeNt

Zuviel des Guten.
Ich hätte erwartet das
01.
sp_removedbreplication 'ha_st40'

ausreicht.

Gruß L.
Bitte warten ..
Mitglied: CeMeNt
17.07.2008 um 16:09 Uhr
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...)
Bitte warten ..
Mitglied: Biber
17.07.2008 um 18:10 Uhr
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
Bitte warten ..
Mitglied: CeMeNt
18.07.2008 um 09:51 Uhr
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
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Windows Server
gelöst SQL-Server Datenbanksicherung inkl. Benutzerberechtigungen dafür? (4)

Frage von 1410640014 zum Thema Windows Server ...

Windows 10
gelöst Installationsproblem sql server 2014 auf windos 10 rechner (23)

Frage von jensgebken zum Thema Windows 10 ...

Hyper-V
SQL-Server auf VM mit Fallback und zweitem Standort (5)

Frage von wolfram.K zum Thema Hyper-V ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (20)

Frage von Xaero1982 zum Thema Microsoft ...

Outlook & Mail
gelöst Outlook 2010 findet ost datei nicht (19)

Frage von Floh21 zum Thema Outlook & Mail ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Festplatten, SSD, Raid
M.2 SSD wird nicht erkannt (14)

Frage von uridium69 zum Thema Festplatten, SSD, Raid ...