Das Update von Empirum 2005 PFP R2 hat unsere Datenbank glatt durchschlagen. Fünf kritische Fehler bei Aktualisierung der Datenbank traten auf. Ergebnis: eine teilmigrierte Datenbank - schwebend zwischen 3.22 und 4.01 - und ein nun defektes System. Dabei könnte man das vermeiden.
- VOR einer Aktion kann man einige Zeilen Code darauf verwenden, zu prüfen, ob die Gegebenheiten vorliegen, die man braucht. Liegen diese nicht vor, wird das Update abgebrochen, ohne dass die Datenbank verändert wurde. Beispielsweise hat eines der Scripte einen Fehler erzeugt, weil eine Rollendefinition in der Datenbank belegt und nicht leer sei, deshalb könne man nichts ändern. Das hätte man vorab prüfen können - und gegebenenfalls das Update ausgesetzt.
- Während einer Transaktion kann man durch Fehlerbehandlung und Rollback-Funktionen den ursprünglichen Zustand der Datenbank wieder herstellen. Man kann grundsätzlich jede Transaktion ungeschehen machen.
Die Sicherungsmöglichkeiten sind bei Transaktionen auf SQL Servern eigentlich Standard. Warum eigentlich nicht bei Matrix42? Ich unterstelle, es gibt einen Grund dafür, der weniger offensichtlich ist, und den ich nicht kenne.
