Fehler (FB+Zeos): internal gds software consistency check...

[lume96]

Hi,

@Hansa:
Was ist den so falsch an seinem Vorhaben ?

Ich frage auch aus Eigeninteresse, ich habe nämlich auch ein Programm mit Firebird embedded und gehe ähnlich vor :
Bei Programmstart wird überprüft, ob 'ne DB existiert, falls nicht :
1) DB anlegen (genauso wie Panthrax)
2) Tabellen, SPs etc erzeugen (mit Hilfe von 'nem Script und TZSQLProcessor).

Sollte ich da besser anders vorgehen ?

Tschüss,
Lutz

[Robert_G]

Zitat:

Zitat von lume96

Sollte ich da besser anders vorgehen ?

Ist schon OK so.
Lass dich da von Hansa nicht zusammen stauchen. Die ZConnection setzt doch auch nur deinen SQL code ab. ;)
Wobei ich mir für kommerzielle Anwendung nicht sicher bin wie sinnvoll die Zeos sind. (Die scheinen ja ziemlich buggy zu sein :? )

[lume96]

Zitat:

Zitat von Robert_G

Ist schon OK so.

Dann bin ich ja beruhigt.

Zitat:

Zitat von Robert_G

Wobei ich mir für kommerzielle Anwendung nicht sicher bin wie sinnvoll die Zeos sind. (Die scheinen ja ziemlich buggy zu sein :? )

Dem kann ich nur zustimmen, obwohl, wenn man die Fehler kennt und umgeht, dann läuft's einigermassen. (Nun ist es in meinem Fall sowieso nur 'n kleines Tool für interne Zwecke; da werden die Zeos nicht besonders beansprucht)

Tschüss,
Lutz

[Hansa]

Ich sage ja nicht, daß man so etwas auf keinen Fall zur Laufzeit machen sollte. Nur sehe ich keinen Vorteil darin. Wozu selber ein Programm dafür schreiben ?

Ist keine DB da, so kann man eine getestete leere kopieren oder eben nicht. Dafür hat man dann das Installationsprogramm für eine leere DB gespart. So etwas widerspricht außerdem meiner Philosophie, dem Enduser möglichst wenig Arbeit zuzumuten. Insbesondere unnötige Entscheidungen, die dann sogar wegen eines Fehlers im eigenen Programm oder den verwendeten Komponenten scheitern könnten.

Solange nicht noch ein grundsätzlicher Vorteil auftaucht, kriegt von mir jeder eine EXE und eine DB. Dazu noch die fbembedded Files und das wars dann. Auch noch ein Mini-Prog zum kopieren der Dateien. Ein mit Delphi geschriebenes DB-Anlege Programm wird definitiv nicht dabei sein.

Und @RG : habe gehört, du kommst auch nach Kassel ? :mrgreen:

[lume96]

Hi,

Zitat:

Zitat von Hansa

Wozu selber ein Programm dafür schreiben ?

Das ist mir auch klar. Allerdings kann man das Erstellen der DB ins Hauptprogramm mit einbeziehen. Davon wird das Programm auch nicht doppelt so gross.

Zitat:

Zitat von Hansa

So etwas widerspricht außerdem meiner Philosophie, dem Enduser möglichst wenig Arbeit zuzumuten. Insbesondere unnötige Entscheidungen, die dann sogar wegen eines Fehlers im eigenen Programm oder den verwendeten Komponenten scheitern könnten.

Der Enduser muss davon ja nicht umbedingt was mitbekommen. Ist keine DB da, dann wird halt eine erstellt.

Was die Fehler der Komponenten betrifft, ob Du die jetzt beim Erstellen der DB oder beim späteren Zugriff auf die DB hast (die Fehler) ist ja wohl unwichtig. Was nützt Dir 'ne getestete DB wenn die Kompos beim ersten Zugriff auf diese DB das Programm abstürzen lassen.

Zusätzlich war meine Idee (bezogen auf ein aktuelles Projekt), in regelmässigen Abständen automatische Back-ups der db anzulegen.

Wenn jetzt die DB fehlt oder aber korrupt ist, kann sie eben schnell neu erstellt werden und das letzte Back-Up, falls vorhanden, eingespeisst werden.

Ist natürlich klar, dass sich das nur auf eine Embedded DB bezieht. Da sehe ich die DB ähnlich wie z.B. 'ne INI-Datei. Die liefere ich auch nicht mit, sondern erstelle sie, wenn ich sie brauche.

Tschüss,
Lutz

[Hansa]

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. :mrgreen: 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. :mrgreen: Nun gut, was solls. Wer sich das antun will der soll es eben so machen. :lol:

[mikhal]

Hast du schon mal was von Versionierung und den SQL Befehl "Alter Table" gehört? Ich habe in meinen Programmen immer einen Test, ob die zugrundeliegende Datenbank auch der aktuellen Version entspricht. Tut sie das nicht, wird die Datenbank entsprechend geändert, dazu gehört eben auch, daß man die Änderungen an Tabellen nachzieht.

Was glaubst du eigentlich, wie in richtig teuren Datenbank-gestützten Programmen gearbeitet wird. Was meinst du, wie lange ein Unternehmen existiert, das mit einer neuen Programmversion eine neue Datenbank fordert und deshalb deine alte Datenbank ins Nirwana schickt?

Der Weg, bei Programmstart zu testen, ob eine Datenbank existiert und sie dann ggf. neu anzulegen ist sehr anwenderfreundlich. Es gibt eine Menge Anwender, für die es ein K.O.-Kriterium darstellt, wenn sie erst eine Datenbank erzeugen müssen (wie auch immer), damit das zu testende Programm auch funktioniert. Nicht jeder, der ein Programm mal eben austesten will, ist bereit und auch dazu in der Lage einen SQL-Server zu installieren, eine Datenbank anzulegen. Oft scheitert es ja bereits daran, daß man die Hinweise zur Installation gar nicht oder erst dann liest, wenn nichts mehr geht.

Ich gebe dir Recht, daß ein Programm, das in einem Unternehmen mit Netzwerkanbindung eingesetzt werden soll, meist genau so daherkommt: Erst Datenbank-Server installieren, dann Datenbank mit Script anlegen, dann Programm installieren, aber wenn ich schon die EMBEDDED-Version der Firebird oder MYSQL verwende, kann ich eigentlich davon ausgehen, daß das Programm NICHT in einem Netzwerk installiert werden soll. Dann ist es Einzelplatz-Version konzipiert und dann erwarte ich als Anwender, daß ich eben keinen Datenbankserver installieren muß.

Grüße
Mikhal

[lume96]

Moin Mikhal,

ich fand meine Vorgehensweise, eine DB gegebenfalls zur Laufzeit zu erstellen auch nicht ganz schlecht. Besonders, wie schon von Dir erwähnt, im Falle eines Updates des Programms. Nun ist es in meinem Fall ja auch so, dass die DB mit Hilfe eines Scripts erstellt wird (das ins Programm geladen wird und dann ausgeführt wird). Abgesehen von einem Fehler im Script sehe ich da nicht die Risiken, die Hansa erwähnt. Ausserdem ermöglicht mir diese Vogehensweise, dynamisch von älteren Versionen der DB auf die aktuelle Version upzudaten (einfach das entsprechende Updatescript laden und fertig) .

Ist klar, dass wir hier über Embedded versions diskutieren. Bei einer Multi-user Umgebung mit DB-Server etc... würde ich auch nicht so vorgehen.

Tschüss,
Lutz