Daten einer Datenbank in 2. DB kopieren

Question

Hallo

Aus einer DB sollen von div. Tabellen die Daten in eine zweite Datenbank kopiert werden.

Über sys.tables würden alle Tabellen gelesen und ein Filter würde die unerwünschten Tabellen ausfiltern. Jetzt gibt es aber zwischen einzelnen Tabellen abhängigkeiten welche während dem kopieren nicht beachtet werden sollten. Es sollte also z.B. möglich sein, die Tabelle mit den Belegen zu kopieren, bevor die Kunden da sind.  Diese folgenden dann bei einer späteren Tabelle, am Schluss wären aber alle nötigen Daten da.

Es gibt doch eine solche Möglichkeit, das zu deaktivieren und danach wieder zu aktivieren.

Gruss Christoph

Answer 1

Schon, ergibt aber nicht unbedingt Sinn, da wenn du zuerst die abhängigen Daten kopierst und dann die Referenzdaten, aber der Filter für die Referenzdaten, mehr löscht als gedacht, ist es schon in die Hose gegangen..

Ich würde über sys.foreign_keys die Reihenfolge der Aktionen steuern

Wobei sich mir die Frage stellt, wie du das mit den Filtern automatisieren willst?

Answer 2

Man kann natürlich alles sauber ausarbeiten und in der richtigen Reihenfolge kopieren, aber für einen ähnlichen Zweck verwende ich folgendes:

ALTER TABLE ' + @QualifiedObjectName + ' DISABLE TRIGGER ALL;
ALTER TABLE ' + @QualifiedObjectName + ' NOCHECK CONSTRAINT ALL;'
...Do Stuff....
ALTER TABLE ' + @QualifiedObjectName + ' ENABLE TRIGGER ALL;
ALTER TABLE ' + @QualifiedObjectName + ' WITH CHECK CHECK CONSTRAINT ALL;'

---

-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org

Answer 3

Das mit dem Disablen der Contraints hat nur den unschönen Nachteil, das diese anschließend dann auf "not trusted" stehen.

select name, is_not_trusted
from sys.foreign_keys

Siehe Foreign Keys or Check Constraints Not Trusted

---

Olaf Helper

Blog Xing

Answer 4

Hallo zusammen

Der Ansatz von Frank gefällt mir. Dass es Risiken gibt, ist klar.

Die letzte Zeile aus dem Beispiel von Frank sollte das is_not_trusted Problem lösen, oder?

Wegen der Tabellen-Filter, da würde ich einfach die betroffenen Tabellen nicht einbeziehen und dann mit allen Tabellen diese Scripts laufen lassen.

Ich werde es damit mal versuchen. Danke.

Gruss Christoph

Answer 5

Hallo zusammen

Der Ansatz von Frank gefällt mir. Dass es Risiken gibt, ist klar.

Die letzte Zeile aus dem Beispiel von Frank sollte das is_not_trusted Problem lösen, oder?

Richtig. Hier noch eine weitere Referenz zu dem Thema: Non-trusted constraints

---

-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org