nicht angemeldet
Hallo,
also wogegen möchtest du dich genau schützen?
Vor jeder Schema-Änderung kannst du ein Backup der Datenbank machen und ggf im Problemfall wieder herstellen.
Du könntest ALTER Scripts verwenden um bestehende Objekte zu ändern.*
Für DDL-Scripts wie z.b. CREATE TABLE / VIEW / PROCEDURE haben wir hier Templates im Einsatz (MS SQL 2000 & 2005), die vor dem Erstellen des Objektes auf dessen existenz prüfen und ggf das existierende löschen. Wir brauchen mittels Search & Replace dann nur noch den Objektnamen, das Schema und natürlich den Body (Prozedur-Code, Tabellendefinition) einfügen.
Mit einem geeigneten Tool** kannst du dann auch aus den verwalteten Scripts eine völlig neue Datenbank quasi "from scratch" aufbauen und gegen eine existierende Datenbank vergleichen. Und dann ggf Änderungen übertragen in Form von ALTER scripts.
* das macht u.U. eine Datenmigration notwendig
** DBGhost kann das für MS SQL 2000 sehr gut, ist aber nicht kompatibel zu MS SQL 2005
Grüsse
Frank
Ich möchte mich dagegen schützen, dass wenn ich ein Skript in die Datenbank einspiele, und es zum Abbruch des Skriptes kommt (aus welchem Grund auch immer), dass dann nur die Hälfte des Skriptes ausgeführt wurde.
Ich bin dabei ein Tool zu entwickeln, welches Skripte sammelt und diese dann automatisch ausführt. Sprich ich habe 10 Skripte um von Version 1.4 auf eine Version 1.5 zu migrieren. Bricht er nach dem 5. Skript ab, kann ich einfach neu starten und mit dem 6. Skript weitermachen. Ist ja kein Problem.
Was kann ich aber machen, wenn 6 bereits gestartet wurde und gewisse Teile ausgeführt wurden?
Klar, könnte man sagen in solch einem Fall muss der Datenbankadministrator (DBA) den Fehler beheben, aber ich suche halt nach Möglichkeiten, die dem DBA die Arbeit erleichern oder ggbf sogar ganz abnehmen. Klar, bei Skripten die einfach eine neue Tabelle erstellen, ist es kein Problem. Wenn die Tabelle existiert, wird sie einfach gelöscht und neu generiert. Aber bei komplexeren Änderungen ist das nicht so leicht möglich.
Vor jeder Änderung (also vor jedem Skript) ein komplettes Backup der Datenbank zu erstellen, ist das nicht ein wenig viel Arbeit? Wieviel Aufwand ist sowas?
Die Daten werden natürlich immer an das neue Schema angepasst!!!
btw.: DB Ghost unterstützt doch SQL Server 2000 und SQL Server 2005 oder nicht?