Abbruch von Schemaänderungsskripten u. damit verbundene Probleme

[heimicha]

Hallo!
Also mir stellt sich folgendes Problem:
Wenn ich ein Skript "A" laufen lasse und es sich um eine Transaktion handelt, ist es kein Problem, wenn es zwischendurch abbricht, da Transaktionen ja rückgängig gemacht werden können.
Was passiert aber bei einem Skript "B" in dem Datenbankschemaänderungen gemacht werden?
Prinzipiell, kann man dann ja nicht einfach das Skript "B" von neuem Starten, sondern muss die schon gemachten Änderungen überspringen.

Kann mir da jemand Hilfestellung leisten, in irgendeiner Art und Weise?

Was mir bisher dazu einfiel ist, dass ich ja z.b. bei einem anlegen einer Tabelle vorher prüfen könnte ob sie schon existiert. Somit könnte ich dann diesen Befehl überspringen und den nächsten ausführen. Aber das hilft natürlich nur in manchen Fällen.
Ich kann ja nicht alles Testen.
Wenn ich beispielsweise Tabellen ändern möchte, kann ich ja nicht jedes einzelne Attribut und sonst was testen, ob alles durchgeführt wurde oder nicht!

Es geht hier übrigens um MS SQL Server 2000+2005 Datenbanken.

Bin für jede Hilfe dankbar!
Michael

[Bernd Schulz]

Hallo!

Da helfen die die Systemtabellen sysobjects und syscolumns weiter!
Dort werden vorhandene Tabellen bzw. Felder abgelegt.

select * from sysobjects where name = 'mytable' and xtype = 'U'

oder

select * from syscolumns where name = 'myfield' and ID = (select ID from sysobjects where name = 'mytable' and xtype = 'U')

BYE BERND

[heimicha]

Die Skripte werden sorgfältig entwickelt und gesammelt und dann zu einem bestimmten Termin von einem Datenbankadministrator in die Datenbank eingespielt. Also das läuft bisher so, soll aber aufgrund der Arbeit, jedes einzelne Skript manuell einzuspielen, weitestgehend automatisiert werden. Der Datenbankadministrator bedient dann nur noch das Tool und kann dann einfach per mausklick eine Datenbank auf eine neue Version heben.

Ich entwerfe gerade ein Tool, was dieses einspielen automatisieren soll.
Es wird eine initiale DB gespeichert und dann daraufaufbauend immer neue Versionen erstellt.
Version 1 würde dann Skripte beinhalten um die initiale DB auf Version 1 zu heben.
Version 2 Skripte um die DB Version 1 auf Version 2 zu heben
usw.

Und deswegen benötige ich halt eine Lösung, welche es ermöglicht bei Abbruch eines Skriptes im besten Falle selbsständig, das Skript dennoch zu Ende zu führen.
Die komplexeste Variante wäre natürlich vor jedem Skript eine komplettes Backup der Datenbank zu machen und bei einem Fehler dieses Backup wiederherzustellen und das Skript erneut auszuführen. Ist aber sehr aufwändig.


Das mit den Systemtabellen sysobjects und syscolumns verstehe ich nicht.
Was ist das genau und was kann ich damit für meinen Kontext erreichen?

[Thomas Rith]

Wie Bernd sagt: Dir bleibt nix anderes übrig, als in den Systemtabellen zu prüfen, ob ein Feld schon so angelegt ist etc., wie Du es brauchst! Aber da hast Du wohl eine ganze Menge zu prüfen Sonst laufen Deine Scripte auch nicht einwandfrei durch...

Gruß
Thomas

[Bernd Schulz]

Hallo!

Ein Beispiel:
Ich möchte in die Tabelle Test das Feld NeuesFeld eintragen und ich habe keine Ahnung, ob es das schon gibt.

if not exists ( select * from syscolumns
where name = 'NeuesFeld' and
ID = (select ID from sysobjects where name = 'test' and xtype = 'U') )
alter table test add NeuesFeld int

Das if sorgt dafür, dass mein alter nur dann "zündet", wenn das Feld noch fehlt.

Wir haben einen etwas anderes Weg gewählt:
Jede Datenbank hat eine Tabelle Version mit einem einzigen Feld Version Typ int und einem einzigen Datensatz. Die Versionsnummer wird einfach als fortlaufende Integer in dieser Tabelle gehandelt.

Wenn ich jetzt im SQL Manager eine Änderung an einer Tabelle durchführe stellt mir der Manager ja ein Änderungsskript zur Verfügung um die Änderungen an der DB durchzuführen.
JEDES einzelne Statement des Skriptes stellt für mich jetzt eine neue Version dar.
Wenn ich ein Update durchführe wird jedes einzelne Statement ausgeführt und danach die Versionstabelle der entsprechenden Datenbank ebenfalls geupdated.
Sollte jetzt das Update stehen bleiben habe ich in der Tabelle Version die letzte durchgeführte Aktualisierung und kann ab dieser Stelle weitermachen.

Alle Änderungen werden in einer Tabelle (zentral gehalten auf unserem Entwicklungsserver) geführt jeweils mit Versionsnummer und Statement. Diese Tabelle stelle ich unserem Updatesystem als XML Datei zur Verfügung. das System liest aus der Datenbank die letzte Versionsnummer und kann jetzt in der XML Datei ab dieser Stelle die Updates fahren. Klappt wunderbar und alle Kunden können ganz leicht immer auf dem gleichen Stand gehalten werden bei minimalen Konflikten.

BYE BERND