Update der Struktur von SQL-Server und MSDE

[Martin Roller]

Hallo,

es geht um die Frage wie Updates für Kunden organisiert werden, wenn sich im Zuge der Weiterentwicklung (es kommen gespeicherte Prozeduren hinzu, es ändern sich welche etc) die DB ändert.

Da weder der Enterprise Manager noch Access (als Frontend) noch nicht einmal ein Änderungsdatum vermerken ist es sehr schwierig herauszufinden, welche Prozeduren beim Kunden geändert/gelöscht/hinzugefügt werden müssen.
Wir haben das bisher so geregelt dass über ein Script alle Proceduren/Views gelöscht und wieder neu eingefügt wurden.

Wie macht ihr das ? Habe ich was übersehen ?

[Sonja Oppermann]

So in der Art habe ich das auch angedacht.
Auf mich kommt das alles erst noch zu, da ich gerade dabei bin, die ersten Demo-Test-Version Pakete zu schnüren.
<P>
Also ganz abwegig ist die Methode wohl nicht.
<P>
Grüsse
Sonj

[Andreas Kosch]

Hallo,

&gt; Wie macht ihr das ?
Wenn man sich einige der Microsoft-Beispielanwendungen ansieht, taucht dort öfters eine Hilfstabelle auf, in der die Versionsnummer der Datenbankstruktur vermerkt ist. Das eigene Installationsprogramm kann dort nachsehen, welche Versionsnummer der Datenbankstruktur vorgefunden wird - um dann nur die Teile zu ändern, die sich von dieser Versionsnummer unterscheiden. Das setzt natürlich voraus, dass man akkurat ein Verzeichnis aller Änderungen einer bestimmten Strukturversion führt.
<br>
Wenn alle Stored Procedures und Views allerdings gelöscht und neu angelegt werden, ist die Angelegenheit einfacher :-

[hwoess]

Auf jeden Fall irgendwie eine eigene Versionsnummer mitführen!
Erstens kann (und solllte) die Anwendung immer prüfen, ob die DB auf dem entsprechenden Stand ist.
Zweitens braucht man das spätestens bei Änderungen in Tabellen. Diese können nicht mehr einfach gelöscht und neu aufgebaut werden.

Ich habe in meinen Anwendungen auch einen Programmteil, der bei jeder Änderung mitwächst, weil er die Scripts beinhaltet (und ausführen kann), um von einer beliebigen Stufe auf die jeweils nächste zu kommen. Damit kann eigentlich nicht viel schiefgehen. Ich hatte dadurch nie ein Problem. Aus Sicherheitsgründen erzwinge ich sogar vorher eine Datensicherung (habe die bisher noch nie gebraucht).

bye,
Helmu

[Martin Roller]

Hallo,

herzlichen Dank für eure Beiträge.

@Helmut: es geht uns nicht um die Aktualisierung der Tabellen, die kann man mit SQL-Statements wie diesem ändern ohne die Tabellen löschen:

--Neues Feld FAuftragsNr in Tabelle Auftragspos anlegen
IF NOT EXISTS (SELECT sysobjects.name, syscolumns.name AS Spalte FROM sysobjects INNER JOIN syscolumns ON sysobjects.id = syscolumns.id
WHERE (sysobjects.name = N'Auftragspos') AND (syscolumns.name = N'FAuftragsNr')) BEGIN
ALTER TABLE Auftragspos ADD FAuftragsNr INTEGER
END
GO

oder den Typ eines Feldes von real auf float ändern:

If exists (SELECT syscolumns.name AS Spalte FROM sysobjects INNER JOIN syscolumns ON sysobjects.id = syscolumns.id
WHERE (sysobjects.name = N'Auftragskopf') AND (syscolumns.name = N'Bruttogewicht') AND (syscolumns.xtype = 59)) BEGIN
Alter Table Auftragskopf alter column Bruttogewicht float
END
GO

Das Problem bilden die gespeicherten Prozeduren, Views usw. da MS das Änderungsdatum nicht, dafür aber das Erstelldatum zweimal(!) abspeichert.
Sonst könnte man anhand des Änderungdatums nur die geänderten Prozeduren durch ein Skript ändern lassen.

@Andreas Kosch: sollte das nicht zutreffen bitte ich um Aufklärung, oder gibt es einen besonderen Grund das Änderungsdatum nicht mitzuführen ?

Alles in allem mutet mich oben beschriebene Vorgehensweise im Zeitalter von RAD und MDA wie "IT bei Steinzeit" an: es ist zeitaufwändig und fehlerträchtig.

Aus diesem Grund habe ich mich umgesehen und Tools entdeckt:
ApexSQL Diff: http://www.apexsql.com/purchase.asp#diff oder http://www.red-gate.com/SQL_Compare.htm

Diese Tools scheinen genau dieses Synchronisationsproblem zu lösen.

Marti