[MSSQL] mehrere Tabellen in eine andere Datenbank kopieren

[Harlequin]

Yerf!

ich hab mal wieder ein Problem mit einer (oder besser gesagt 2) MSSQL Datenbanken. Ich muss Daten aus mehreren Tabellen (vollständiger Tabelleninhalt) in eine andere Datenbank mit identischer Struktur übertragen, stoße dabei aber auf Probleme wegen vorhandener Fremdschlüssel wenn ich das über den Export-Assistenten des Management Studios probiere (Error beim Truncate der Ziel-Tabellen)

Ich muss die vorhandenen Daten in den Tabellen in der Zieldatenbank erst löschen bevor ich die neuen Daten schreibe, das scheitert aber daran das es Fremdschlüsselbeziehungen gibt. Gibt es eine Möglichkeit für die Zeitdauer dieser Transaktion die Prüfung der Integrität zu unterbinden? (entweder im Assistenten oder als Skript) Nach dem vollständig abgeschlossenen Kopiervorgang sollten wieder alle Beziehungen passen (falls nicht darf mir die Datenbank dann gerne einen Fehler um die Ohren werfen, aber bitte nicht vorher ;-)

Das ganze findet auf einem SQL Server 2008 (10.50.4000) statt, die Datenbanken hängen an der selben Server-Instanz.

Hat jemand einen Ansatz für mich? Google & Co. liefert mir irgendwie nichts brauchbares (ist vor allem auch ständig der Meinung ich hätte mich verschrieben und würde eigentlich MySQL meinen...). Ein guter Link für weitere Informationen würde mir erst mal schon reichen.

Gruß,

Harlequin

[dedlfix]

Tach!

Gibt es eine Möglichkeit für die Zeitdauer dieser Transaktion die Prüfung der Integrität zu unterbinden?

Meines Erachtens nicht. Die Datenbank müsste dann ja auch irgendwie gesperrt werden, dass nur du zugreifen kannst und kein anderer in die nicht vorhandene referenzielle Integrität tappt. Was aber gehen müsste, den Schlüssel zu löschen und hinterher wieder zu setzen.

dedlfix.

[Harlequin]

Yerf!

Die Sperre wär an sich kein Problem, ich hab die Datenbank lokal ganz für mich alleine ;-)

Hm, die Schlüssel löschen wär noch so ne Holzhammer-Methode... wollt ich eigentlich vermeiden. Aber wenn ich nichts anderes finde wirds wohl darauf hinauslaufen.

Wobei ich auch mal den anderen Ansatz erst mal verfolgen werde ob ich nicht doch eine Reihenfolge finde in der das ganze klappt. Schade das es wohl nicht über den Assistenten geht... hätt mit eineiges an SQL-Skripting erspart.

Gruß,

Harlequin

[dedlfix]

Tach!

Die Sperre wär an sich kein Problem, ich hab die Datenbank lokal ganz für mich alleine ;-)

Davon kann man bei eienr Datenbank nicht unbedingt ausgehen, weswegen das eher kein Feature ist, für das eine Implementierung ins Auge gefasst wird.

dedlfix.

[Daniel.S]

Guten Abend,

Ich muss die vorhandenen Daten in den Tabellen in der Zieldatenbank erst löschen bevor ich die neuen Daten schreibe, das scheitert aber daran das es Fremdschlüsselbeziehungen gibt. Gibt es eine Möglichkeit für die Zeitdauer dieser Transaktion die Prüfung der Integrität zu unterbinden?

Ich habe nicht viel Erfahrung mit MSSQL, daher weiß ich nicht, ob es so etwas gibt.
Aber du kennst doch sicher das Datenmodell deiner Anwendung. Beginne mit der Löschung von Daten in der Tabelle ganz rechts (auf Datensätze dieser Tabelle zeigen keine Sätze aus anderen Tabellen). Sind diese Datensätze gelöscht, fahre mit der ersten Tabelle von rechts fort, die Datensätze enthält (auf diese Zeigen ja nun keine weiteren Sätze mehr).

Wenn du dein Datenmodell kennst, kannst du diese Schritte automatisieren.

Hat jemand einen Ansatz für mich? Google & Co. liefert mir irgendwie nichts brauchbares (ist vor allem auch ständig der Meinung ich hätte mich verschrieben und würde eigentlich MySQL meinen...). Ein guter Link für weitere Informationen würde mir erst mal schon reichen.

Eine Idee wäre, ein Backup der Originaldaten zu erstellen und dieses in der Kopie-DB einzuspielen. ich weiß allerdngs nicht, wie das von MSSQL gehandhabt wird.

Gruß, Daniel

[Harlequin]

Yerf!

Ich habe nicht viel Erfahrung mit MSSQL, daher weiß ich nicht, ob es so etwas gibt.
Aber du kennst doch sicher das Datenmodell deiner Anwendung. Beginne mit der Löschung von Daten in der Tabelle ganz rechts (auf Datensätze dieser Tabelle zeigen keine Sätze aus anderen Tabellen). Sind diese Datensätze gelöscht, fahre mit der ersten Tabelle von rechts fort, die Datensätze enthält (auf diese Zeigen ja nun keine weiteren Sätze mehr).

Ich muss mir das ganze nochmal anschauen, es sollte wohl gehen wenn ich die Daten per Delete statt Truncate selbst lösche und dann den Import auch in der richtigen Reihenfolge durchführe (per select into oder so). Das Problem ist das ich das Datenmodell auch noch nicht komplett durchschaut hab... muss mir die Schlüsselbezieheungen noch mal genauer ansehen.

Export/Import scheitert momentan eben am löschen der Daten in der Zieldatenbank und auch beim reinspielen bin ich mir nicht sicher ob er es in der richtigen Reihenfolge macht. Ich kopier dabei auch nicht alle Daten sondern nur einen Teilbereich. Schlussendlich eine Reparaturmaßnahme, die wichtigen Daten aus einer "verhunzten" Datenbank in eine saubere umziehen, die saubere hat aber teilweise auch schon ein paar Grunddaten drin die erst raus müssen, damit nachher ganz sicher die Beziehungen stimmen (identity insert) und nichts doppelt ist.

Gruß,

Harlequin

[Jürgen]

Hallo,

zum MS-SQL-Server gehört ein Migration Tool.

Wenn Du das nicht hast, gibt es unter "ms sql migrate tables" in der unendlihen Müllhalde dutzende von guten und schlechten Tipps.

siehe auch: http://stackoverflow.com/questions/187770/copy-tables-from-one-database-to-another-in-sql-server

Auch Gruß
Jürgen

[Jürgen]

Hallo nochmal,

falls Dir das was nützt:
Mein Kollege sagt gerade, Du sollst dir "merge" mal angucken.
http://msdn.microsoft.com/de-de/library/bb510625.aspx

So, nun wünsch ich euch allen frohe Pfingsten

So long
Jürgen

[Harlequin]

Yerf!

Merge sieht vielversprechend aus... werd ich mir morgen nochmal direkt mit meinen Daten anschauen, aber evtl. kann ich mir damit das Löschen sparen, denn die vorhandenen Datensätze in der Zieldatenbank sind Defaults die eigentlich in beiden Datenbanken identisch sein sollten, aber das muss ich nochmal gegenchecken (an der Quelldatenbank ist so einiges "kaputt")

Gruß,

Harlequin