Ich glaube ich gebs auf. Der Vergleich von INI Dateien mit einer leeren Datenbank ist gar nicht so schlecht. In beiden Fällen geht es um die Festlegung von bekannten Standardvorgaben. Wenn diese aber sowieso bekannt sind und einmalig gespeichert werden müssen, dann mache ich mir doch nicht die Mühe meine Vorgaben mit einem eigens dafür entwickelten Programm zu hinterlegen, sondern liefere direkt die Dateien mit.
Sollte sich später was ändern, dann gibt es aber zwischen INIs und
DB gewaltige Unterschiede. Die INI Dateien würde ich auch innerhalb meines Programmes behandeln. Z.B. Mwst. ist in INI hinterlegt und ändert sich. Der Enduser sollte das schon ändern können, oder eben zumindest die INI editieren. Bei einer Datenbank ist so was undenkbar. Man könnte eventuell einige Stored Procedures neu rein machen und dazu gibt es bei IBExpert IBEScript. Natürlich auch mit neuem Programm und auch neuem
DB-Installationsprogramm. Änderungen an den Tabellen kann man vergessen, ohne auch das Programm neu zu machen. Auch die neuen SPs nützen absolut nichts, wenn sie vom Programm nicht genutzt werden.
Und dann noch das K.O. Kriterium : Was ist mit den vorhandenen Daten ? Wenn ein einziges Feld von integer auf real umgestellt wird ist Schluß mit lustig und es geht richtig schön los.
Die
DB weiß nichts von dem angeforderten real Feld und das Programm weiß nichts davon, was die
DB für ein integer-Feld haben will. Was machen ? Alles löschen ! Mühsam neues Installationsprogramm schreiben, anstatt notfalls die neue umgebaute
DB leer neu auszuliefern.
Und das Argument mit eventuellen Fehlern in den Zugriffskomponenten zieht auch nicht. Ist das Programm an sich ohne Fehler und nur das
DB-Inst.Programm hat einen Bug, dann kann das fehlerfreie eigentliche Programm wegen nicht vorhandener/nur teilweise vorhandener
DB nicht laufen. Und das trotz der vielen Arbeit, die in dem unnötigen Inst.Programm drin steckt.
Nun gut, was solls. Wer sich das antun will der soll es eben so machen.
