Datenbank gleich halten bei sich und Endanwendern

[etom291272]

Hallo Leute erstmal schönen Sonntag

Folgendes Problem:
Habe letzte Woche mein neues Produkt (natürlich zu 100% in Delphi geschrieben) das 1. Mal bei einem Kunden unserer Firma installiert. weitere werden folgen
Dieses Produkt wird aber von mir in den nächsten Monaten noch umfangreich weiterentwickelt sodass sich die Datenbankdefinitionen in meiner Entwicklungsumgebung sicher noch oft ändern wird.
Habe mich zwar bemüht wenig Funktionalität in die Datenbank zu packen aber es werden tabellen, felder in bestehenden Tabellen und Sichten dazukommen oder sich ändern.

Habe keine grosse Lust dass immer mit dem Enterprisemanager beim Kunden manuell nachzuvollziehen und dass kann ja auch nicht die lösung sein wenn man dann irgendwann zig intallationen draussen hat.

Nach meinem jetzigen wissenstand würde ich sagen mit befehlen wie alter table und so durch code die änderungen auf den selben stand bringen aber dass stelle ich mir vor wie flöhe huten.
Also wie löst man dieses Problem professionell

Danke für eure Hilfe

[alcaeus]

Hallo etom,

wir verkaufen eine WW-Verwaltung inkl. CRM, welches auch auf einer sehr grossen Datenbank basiert. Wir arbeiten mit 3 Versionen (Release, Build, New Version), von welchen 2 bei Kunden installiert sind (Release und Build). Zwischen den einzelnen Versionen bestehen nicht allzuviele Unterschiede, die NV ist aber sehr viel weiterentwickelt. Deshalb haben wir ein Programm namens GenDB entwickelt. Dieses Programm wird immer mit den aktuellsten DB-Schemen ausgeliefert (fuer die jeweilige Version). Das Programm geht nun das Schema fuer die Datenbank durch, und sucht sich die entsprechende Tabelle raus. Existiert die Tabelle nicht, so wird sie erstellt. Existiert sie, so werden die Felder im Script und in der Tabelle verglichen. Fehlt ein Feld oder ist es zu kurz (z.B. bei Varchar-Feldern), so wird das Feld hinzugefuegt/geaendert. Ist ein Feld in der DB, aber nicht im Script so wird eine Meldung in das Log geschrieben, da das Programm grundsaetzlich keine Daten loescht. Aus diesem Grund werden Tabellen die nicht mehr im Script sind auch nicht geloescht.
Dies funktioniert in ca. 90% aller Faelle. Falls Primaerschluessel geaendert werden oder Tabellen geloescht werden muessen, so muessen wir einfach eine Funktion mit in die DLL reinpacken, die die entsprechenden Aenderungen durchfuehrt (also Tabelle erstellen, Daten rueberschieben, alte Tabelle loeschen, anhand von neuem Schema erstellen, dann Daten in die neue Tabelle pumpen und temporaere Tabelle loeschen). Wie genau dies funktioniert kann ich dir auch noch nicht sagen, ich hatte mit dem Programm noch nicht allzuviel Kontakt, da ich erst seit 2 Monaten dort arbeite. Ich hoffe du kannst aber ein paar Ideen verwenden.

Greetz
alcaeus

[Marcel Gascoyne]

Der Weg über ALTER TABLE usw. ist genau richtig. Du solltest Dir aber in einer Tabelle Versionsinformationen speichern, z.b. aktuelle Version der Datenbank und dazu passende Versionen Deiner Anwendung.

So kannst Du dem Anwender mitteilen wenn seine Version nicht zur Datenbank passt und evtl. ein Update der Datenbank anbieten.

Gruß,
Marcel

[etom291272]

Danke für die Antworten hatte schon so etwas befürchtet dass werden wieder lange nächte

gibts vielleicht so ein programm was datenbanken anpassen kann schon fertig (auch wenns was kostet) z.b exportieren der definitionen der new version programm vergleicht dann datenbank bei kunden und passt automatsch an

[Jelly]

Zitat von etom291272:

Danke für die Antworten hatte schon so etwas befürchtet dass werden wieder lange nächte

Leg deinen Kopf mal in Ruh und konzentrier dich auf andere Sachen. Genau das Problem hatte ich auch mal, eben in Verbindung mit MSSQL, und hab mir ne Kompo zu geschrieben... Ich wühl die mal raus und werd sie hier posten. Muss nur noch ein paar Änderungen dran vornehmen.

[Jelly]

OK, hab dann mal los. Die Lösung ist sicherlich nicht allzu bequem, aber sie klappt.

Als erstes brauchst du in deiner Datenbank folgende Tabelle.

SQL-Code:

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[VersionInfo]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[VersionInfo]
GO

CREATE TABLE [dbo].[VersionInfo] (
   [ID] [int] IDENTITY (1, 1) NOT NULL ,
   [Datum] [datetime] NOT NULL ,
   [Major] [int] NOT NULL ,
   [Minor] [int] NOT NULL ,
   [Release] [int] NOT NULL ,
   [Build] [int] NOT NULL ,
   [Script] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
   [Runned] [bit] NOT NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Im ZIP File sind dann die nötigen Dateien. Zu installieren sind darunter die Komponten FileInfo und GxDBScript.

Im File dmDBVersion gibts dann die Methode CheckDBVersion. Zuvor die Zugriffsdaten von TDatabase setzen.

Bei Aufruf von CheckDBVersion wird im Unterverzeichnis Scripts (aus Sicht der EXE-Datei) nach Update-Skripten gesucht. Die Namensgebung der Skripte muss die Form:
v.xx.yy.zz.bb.txt
haben
xx: Major Version
yy: Minor Version
zz: Release
bb: Build
Die Skriptversion wird mit der aktuellen Version der EXE Datei verglichen. Diese Versioninfo muss also in den Projektoptionen definiert sein. Ist die Version des Skriptes älter oder gleich als die Version der EXE Datei, und wurde das Skript noch nicht ausgeführt, so geschieht dies und wird als ausgeführt in der Tabelle VersionInfo in der DB gekennzeichnet.

Ich weiss, die Anwendung ist nicht gerade elegant gelöst, aber ich kam noch nicht dazu, das Ganze in eine gescheite, eigene Komponente zu packen. Aber es funktioniert. Du musst nur noch dafür sorgen, daß du sämtliche Änderungen, die du in der Datenbank vornimmst, auch gleich in die Skriptdatei übernimmst.

[etom291272]

@ jelly

erstmal grosses daaaanke bin mal kurz über die Sourcecodes geflogen sieht sehr interessant aus

nächste Frage von mir warscheinlich nicht besonders intelligent aber:

Habe ich dass so richtig verstanden ? im verzeichnis script liegen als textdatei die scripten für die datenbankmanipulation (also die alter table befehle und so)

muss ich jetzt wirklich bei jeder änderung die ich an der datenbank mache ein script schreiben dass im prinzip das selbe macht wie ich mit dem enterprisemanager oder gibt es eine andere möglichkeit

Optimale Lösung sähe bei mir so aus
die scripte der tabellen und sichten einfach mit dem enterprise manager zu exportieren und ein programm vergleicht dann die datenbank die in diesen textdateieien definiert sind mit der wirklichen Datenbank beim kunden und generiert die notwendigen scripten der änderung automatisch und führt sie durch.

was hältst von dieser idee möglich wäre auch die datenbank leer als kopie ausliefern und die beiden datenbanken vergleichen müsste doch auch gehen

[Jelly]

Zitat von etom291272:

muss ich jetzt wirklich bei jeder änderung die ich an der datenbank mache ein script schreiben dass im prinzip das selbe macht wie ich mit dem enterprisemanager oder gibt es eine andere möglichkeit

Mit meiner Methode: JA. Aber ich seh darin kein großes Problem, wenn du dir bei jeder Änderung an der DB angewöhnst, sie auch gleich im Skript zu speichern.

Unter Firebird gibts das Tool ibcmpibe für IBExpert. Vielleicht gibts was Vergleichbares für MSSQL. Würd mich auch mal interessieren, wenns das gäbe.

[Generalissimo]

Im Enterprisemanager gibt es eine Option mit der nach jedem ändern der Datenbankobjekte ein Änderungsskript automatisch erzeugt werden kann. Es gibt eine checkbox wenn du auf speichern nach der Änderung gehst. Text: Änderungsskript automatisch nach jedem Speichern erstellen

[Jelly]

Und wo. Ich kann diese Option nich finden.