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

[Panthrax]

Hallo.

Ich erhalte folgenden Fehler: internal gds software consistency check (cannot find tip page (165)).

Ich benutze: Zeos (Komponente TZConnection) und Firebird Embedded Server

So ist das ganze verpakt:

Delphi-Quellcode:

...

    // in der Klassendefinition von TForm1
    private
    ZConnection1 :TZConnection;

...

procedure TForm1.FormCreate(Sender: TObject);
begin
  (*ZConnection1.Properties.Add(
    'CreateNewDatabase=CREATE DATABASE ''MyDB.fdb'' '+
    'PAGE_SIZE=8192 USER ''SYSDBA'' PASSWORD ''masterkey''; '+
    '');(**)
  ZConnection1.Connect;
  ZConnection1.Disconnect;
  ZConnection1.Properties.Clear;
  ZConnection1.Connect;
end;

Die Einstellungen von ZConnection1 im Objektinspektor sind:
AutoCommit: True
Connected: False
Database: '.\MyDB.fdb'
HostName: ''
Password: 'masterkey'
Protocol: 'firebird-1.5'
ReadOnly: False
TransactionIsolation: tiNone
User: 'SYSDBA'

Vor dem ersten Programm lauf existiert die Datei './MyDB.fdb' nicht.

Im 1. Programmlauf (F9) ist der oben auskommentierte Programmblock nicht auskommentiert. Das Programm startet und es tritt keine Exception auf. Ich beende das Programm wieder.

Die Datei './MyDB.fdb' existiert und ist 1,04 MB (1.097.728 Bytes) groß.

Im 2. Programmlauf (F9) wird die Prozedur wie oben angegeben ausgeführt. Es tritt die Exception auf.

Delphi-Debugger-Meldung:

Im Projekt Project1.exe ist eine Exception der Klasse EZSQLException aufgetreten. Meldung: 'SQL Error: internal gds software consistency check (cannot find tip page (165)). Error Code: -902. Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements'. Prozesswurde angehalten. Mit einzelne Anweisung oder Start fortsetzen.

Ich bitte um Hilfe. Ich weiß nicht weiter... :coder2:

Warum tritt der Fehler auf?

Panthrax

[Panthrax]

Um das Kernproblem nachvollziehbar zu gestalten, habe ich einen kleinen Flash-Film erstellt. Ich zeige, wie ich mit mit Delphi, allein unter Benutzung der wesentlichen Komponente TZConnection, zur Exception komme.

Exception Demo (ca. 3MB, 5:48min), zum Betrachten den Browser idealerweise maximieren (F11)

Bitte nicht wundern, während der Flash-Film lädt, macht Lycos ein bisschen Werbung. Beim Ende hab ich ein bisschen knapp geschnitten, das letzte Wort ist nicht mehr ganz 'drauf'.

Ich hoffe es hilft beim verstehen und helfen.

Mir ist die Erleuchtung immer noch nicht gekommen... :coder2:

... so stellt sich für mich immer noch die Frage: Warum tritt der Fehler auf?

Panthrax

[dizzy]

Ich habe zwar keine Lösung zu dem Problem, aber ich wollte nur kurz mitteilen, dass das die gelungenste Fehlerbeschreibung war die mir bis Dato untergekommen ist! :thumb:
Illustrativer geht es kaum noch.

Mit welchem Tool hast du das aufgenommen?

Schönen Gruss,
Fabian

[Luckie]

Zitat:

Zitat von Panthrax

Exception Demo (ca. 3MB, 5:48min), zum Betrachten den Browser idealerweise maximieren (F11)

:thumb: Ich habe das Video interessierter verfolgt, als so manche Gerichtsshow auf RT oder SAT. :mrgreen:

[lume96]

Moin,

gib mal in dem create database statement ein default character set an, z.B.:

SQL-Code:

  ZConnection1.Properties.Add('set sql dialect 1;');
  ZConnection1.Properties.Add(
    'CreateNewDatabase=CREATE DATABASE ''MyDB.fdb'' '+
    'PAGE_SIZE=8192 USER ''SYSDBA'' PASSWORD ''masterkey'' DEFAULT CHARACTER SET ISO8859_1; '+
    '');

Tschüss,
Lutz

[Hansa]

Das Filmchen gucke ich mir nachher noch an. So ca. 16:00 wenn die Gerichtsshows kommen. :mrgreen: Allerdings habe ich folgende Vermutung : beim ersten Lauf geht doch das Programm oder ? Wird es denn tatsächlich komplett beendet ? Nicht nur in Delphi sondern auch auf Datenbankebene ? Sind alle Transaktionen tatsächlich beendet ?

Es geht mir darum, daß FB embedded eben ein lokaler Server ist. Also kann nur ein Prozess drauf zugreifen. Viele denken, daß sei eine Einzelplatz Datenbank, aber es kann auch nur mit einem Programm darauf zugegriffen werden :!: Natürlich nur zur selben Zeit !!

[Robert_G]

@Hansa
Genau. Wenn sich die Delphi IDE (Also die ZConnection im Designer) die DB schnappt, kann deine Debug session nicht mehr darauf zugreifen. ;)

[lume96]

Moin,

@Hansa, Robert_G :
In diesem Falle wäre die Fehlermeldung aber anders, so im Stil :
"Datei konnte nicht geöffnet werden, ist schon von einem anderen Prozess in Gebrauch."

Das Problem liegt hier wohl eher im fehlenden DEFAULT CHARSET im Create DB Statement. Das scheint zu einer korrupten DB zu führen.

Tschüss,
Lutz

[Panthrax]

Eureka!

@dizzy: Dankeschön. Ich habe es mit BB Flashback aufgenommen.

@Luckie: Vielleicht hat das, was der neumod'sche Volksmund als eLerning bezeichnet, ja doch die Kraft sich gegenüber zweifelhaften Fernsehsendungen durchzusetzten. (...)

@Lume96: Ich habe ein Default-Character-Set angegeben. Und - es funktioniert! Die Datenbank lässt sich wieder öffnen in einem zweiten, dritten, vierten,... Programmlauf. Ich danke dir für den Hinweis! :thumb:

An anderer Stelle im Netz (Quelle hab ich grad nicht parat) wird gesagt, dass mit den Zeos Komponenten in Verbindung mit Interbase/Firebird die Defaulteinstellung beibehalten werden sollte. Die Defaulteinstellung für den SQL-Dialekt ist 3.

@Hansa: Ich glaube das Filmchen kannst du aus deinem Nachmittagsprogramm streichen. Das Programm läuft jetzt ohne Exception. Aber wenn du unbedingt magst... Ich lass es noch eine weile im Netz.

Es ist ja nicht so, dass ich überhaupt nicht auf die Datenbank zugreifen konnte. Es ging immer nur beim ersten Mal - in dem Programmlauf in dem die DB auch erstellt wurde. Jeder weitere Programmlauf, in dem die Datenbank nicht erzeugt wurde, endete in einer Exception. (Die DB war für diese Programmläufe natürlich bereits vorhanden.)

Was den Programmierstil an geht: Lange bevor ich auf Delphi umstieg, habe ich mit Pascal gearbeitet. Pascal ist nicht ao mütterlich mit einem umgegangen; man hatte stets selbst alles wegzuräumen. Diesen Programmierstil habe ich in Delphi beibehalten, auch wenn es unter Delphi scheinbar "nicht notwendig" ist. Das fehlende Disconnect aus meinem Einstiegsbeitrag steht in der FormDestroy-Methode. Für den Film habe ich darauf geachtet, dass alles optisch beieinander ist, und nicht noch eine zweite Methode begonnen.

@Robert_G: Die Problematik um die unterschiedlichen Zugriffe seitens IDE und Programm bei Ausfhrung habe ich gewusst. Ich hatte die Verbindung in der IDE nicht offen. - Ging ja auch nicht, die IDE hat mir beim setzen von Connected:=True im Objektinspektor den selben Fehler gemeldet, wie das Programm zur Laufeit.

Für den Fall, dass die Datenbank nicht geöffnet werden kann, weil die Dateizugriffsrechte fehlen, hatte ich einen andersgearteten Fehler erwartet. Da simme ich mit Lume96 überein.

@Lume96 (2): So ähnlich hatte ich auch gedacht.


Hier noch ein paar Links zum Thema Default Character Set:

• Erklärungen zum Default Character Set (englisch)
• Auf der Seite von Firebird Character Sets & Collations (englisch)

[Hansa]

Zitat:

Zitat von Panthrax

...Es ist ja nicht so, dass ich überhaupt nicht auf die Datenbank zugreifen konnte. Es ging immer nur beim ersten Mal - in dem Programmlauf in dem die DB auch erstellt wurde.

Na so was aber auch. 8) IMHO einer der größten Fehler die bei Datenbanken gemacht werden: Datenbank immer neu anlegen bzw. sogar Programm dafür schreiben. Was soll das nützen ? Die DB legt man einfach mit einem SQL-Script an und das wars. Die Anfangsfrage wäre gar nicht erst aufgetaucht.

[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