| 

.NET C# Java Javascript Exception

3
Irgentwie hab ich gedacht, dass man mit dem DB-Projekt in VS2010 in der Lage ist, verschiedene Versionsstände von Datenbanken (Schema und Daten) zu behandeln.

Wir brauchen eine Möglichkeit die verschiedenen Versionen unserer datenbank im Projekt unterzubringen. Es gibt Kunden die haben die Version 1.0 andere haben schon 1.3. Wenn wir ein Update dann an den Kunden mit 1.0 liefern, soll das Update von 1.0 auf 1.4 aktualiesern und bei dem anderem von 1.3 auf 1.4.

Ist das mit dem DB-Projekt-Typ Visual Studio 2010 lösbar? Ist dass das falsche Tool? Irgentwie komme ich damit nicht klar
28.02.2012
MyKey0815 1,6k 2 9
3 Antworten
1
Ob es in einem VS-Projekt eine spezielle Unterstützung für das Thema gibt, weiß ich nicht. Ich weiß, dass wir das in Access-VBA erfolgreich ausprogrammiert haben:

Die Datenbank enthält in einer Settingstabelle ein Setting DbVer, der Einfachheit halber als ganze, bei uns dreistellige Zahl: z.B. 130, im GUI dargestellt als 1.3.0. Bei euch würde eine zweistellige Zahl vielleicht ausreichen. Eine Konstante cDbVer im VBA-Projektcode "weiß", mit welchem Versionsstand dieses Frontendrelease zusammenarbeiten will. Bei jedem Start des Frontends vergleicht das VBA-Projekt DbVer und cDbVer miteinander:

* Wenn DbVer > cDbVer, wird der Nutzer informiert, dass er das Frontend updaten sollte.
* Wenn DbVer = cDbVer, passiert gar nichts, das Produkt startet weiter durch.
* Wenn DbVer < cDbVer, wird dem Nutzer die Datenbankaktualisierung angeboten.

Und die Datenbankaktualisierung arbeitet immer nur das ab, was nötig ist, um die Datenbank von ihrer DbVer auf den per cDbVer verlangten Versionsstand zu bringen (einfaches If vor jedem Block von Anweisungen, die jeweils zu einem Versionssprung gehören, also:
If DbVer < 14

<Prüfungen, VBA- und SQL-PassThrough-Anweisungen>


If DbVer < 13

<Prüfungen, VBA- und SQL-PassThrough-Anweisungen>


Die meisten Schritte setzen eine initial auf True gesetzte blnSuccess auf False, wenn sie Fehler werfen, nur manche halten wir für so unwichtig, dass sie den Erfolg des Aktualisierungsunternehmens ingesamt nicht gefährden. Bleibt blnSuccess über alle "heute" einzuschließenden Aktualisierungsschritte hinweg True, setzt die Aktualisierungsprozedur DbVer auf cDbVer, sonst nicht -> beim nächsten Frontendstart wird die Aktualisierung wieder versucht.

Wir haben seit ein paar Jahren trotzdem jedem Schritt eine Prüfung vorgeschaltet, z.B., ob eine hinzuzufügende Spalte / Feld nicht schon existiert. Es lohnt sich, das zu kapseln. Lässt man das Programm prüfen, muss man im Fehlerfall nicht jeden Aktualisierungsschritt einzeln überprüfen, sondern kann auch DbVer manuell "verjüngen" und so die Datenbankaktualisierung von einem vom technischen Support als sinnvoll angesehenen Stand an überprüfen lassen.

Mittlerweile ziehe ich diese individuell programmierte, sehr ausgereifte Lösung jeder denkbaren externen Unterstützung vor. Ich werde erst dann neu nachdenken, wenn der M$SQL selbst in der Lage ist, die Struktur einer Datenbank an eine Vergleichsdatenbank anzupassen. Daran arbeitet M$, aber es läuft noch nicht zufriedenstellend. Könnte aber bereits okay sein.
28.02.2012
mupan 575 1 8
1
Im DB-Projekt hast Du immer nur eine Version der Datenbank. Über das Schema-Update kannst Du diese Version mit einer Ziel-Datenbank vergleichen und ein Change-Script erstellen, um diese auf die aktuelle Version zu aktualisieren.
Ich würde in den Einstellungen für den Schema-Vergleich in diesem Fall einige Datenbank-Elemente (z.B. Benutzer) ausschließen. Sonst schmeißt Dir das Change-Script z.B. alle Benutzer in der Zieldatenbank raus, die nicht im DB-Projekt enthalten sind.
29.02.2012
thomas.ccgdev 161 1 5
0
Das einzig brauchbare Tool auf dem Markt ist - meiner Erfahrung nach - Redgate SQL Source Control:

http://www.red-gate.com/products/sql-development/sql-source-control/
01.03.2012
FrankHell 223 1 7

Stelle deine Mssql-Frage jetzt!