Diagnosehilfen beim Kompilieren

 Es gibt drei Arten, die beim Analysieren und Korrigieren von Datenbanken unterstützen:

• Die aktuelle Analysehilfe ist über die Symboldatei verfügbar. Über diese Tabelle finden Sie rasch durch Ihre Variablen durch. Sie ist ein wertvolles Werkzeug zum Interpretieren der Fehlermeldungen, die der Compiler erstellt.
• Die Korrekturhilfe ist über die Fehlerdatei verfügbar, die Sie als Textdatei verwenden können.
• Die Ausführungshilfe bzw. Bereichsprüfung bietet weitere Hilfsmittel zum Überwachen der Konsistenz und Verlässlichkeit Ihrer Anwendungen.

Hinweis: Eine wichtige Hilfe ist auch die Typisierung von Variablen über die automatischen Compilermethoden. Weitere Informationen dazu finden Sie im Abschnitt Typisierungen.

Die Symboldatei ist eine Textdatei vom Typ ASCII (text only), deren Länge von der Größe Ihrer Datenbank abhängt. Diese Datei wird während dem Kompilieren nicht standardmäßig erzeugt. Dazu müssen Sie in den Datenbank-Eigenschaften auf der Seite Compiler die Option Symboldatei erzeugen aktivieren. Weitere Informationen dazu finden Sie im Abschnitt Optionen zum Kompilieren. Die erzeugte Datei liegt im gleichen Ordner wie die Strukturdatei der Datenbank. Sie lautet DatenbankName_symbols.txt. 

Die Symboldatei könnte folgendermaßen aussehen, wenn sie mit einem Texteditor geöffnet wird:

Der Kopfteil zeigt den Namen der Datenbank sowie Datum und Uhrzeit der Erstellung. Das Dokument ist in vier Bereiche gegliedert:

• Liste der Interprozessvariablen
• Liste der Prozessvariablen
• Liste der lokalen Variablen in ihren Methoden
• Komplette Liste der Projekt- und Datenbankmethoden mit den dazugehörigen Parametern – sofern vorhanden

Diese beiden Listen sind in vier Spalten unterteilt:

• Die erste Spalte enthält die Namen der Variablen und Arrays, die in Ihrer Datenbank verwendet werden. Sie erscheinen in alphabetischer Reihenfolge.
• Die zweite Spalte enthält die Art der Variablen. Die Arten werden über die Compiler-Befehle bestimmt oder über den Compiler, der sich nach der Verwendung der Variablen richtet. Lässt sich der Variablentyp nicht bestimmen, ist die Spalte leer.
• Die dritte Spalte zeigt die Anzahl der Dimensionen, wenn die Variable vom Typ Array ist
• Die vierte Spalte enthält eine Referenz auf den Kontext, in welchem der Compiler den Variablentyp bestimmt hat. Wird die Variable in verschiedenen Kontexten verwendet, wird der Kontext genannt, welchen der Compiler zur Bestimmung des Typs verwendet.
  
  • Wurde die Variable in einer Datenbankmethode gefunden, wird ihr Name wiedergegeben wie in 4D definiert, beginnend mit (M)*.
  • Wurde die Variable in einer Projektmethode gefunden, wird sie identifiziert wie in 4D definiert, beginnend mit  (M).
  • Wurde die Variable in einem Trigger (Tabellenmethode) gefunden, wird der Tabellenname wiedergegeben, beginnend mit (TM).
  • Wurde die Variable in einer Formularmethode gefunden, wird der Formularname wiedergegeben, beginnend mit  (FM) und mit vorangestelltem Tabellennamen.
  • Wurde die Variable in einer Objektmethode gefunden, wird der Name der Objektmethode wiedergegeben, beginnend mit (OM) und mit vorangestelltem Formular- und Tabellennamen.
  • Ist die Variable ein Objekt in einem Formular und erscheint sie weder in einer Projekt-, Formular-, Objektmethode oder Trigger, wird der Name des Formulars wiedergegeben, in dem sie erscheint, beginnend mit (F).
  Am Ende jeder Liste finden Sie die Größen der Prozess- und Interprozessvariablen in Bytes.

Hinweis: Der Compiler kann beim Kompilieren nicht feststellen, in welchem Prozess eine bestimmte Prozessvariable verwendet wird. Eine Prozessvariable kann in jedem Prozess einen anderen Wert haben. Folglich werden alle Prozessvariablen systematisch dupliziert, wenn ein neuer Prozess gestartet wird. Von daher empfiehlt es sich, auf den Speicherplatz zu achten, den sie beanspruchen. Bedenken Sie auch, dass der Platz für Prozessvariablen nicht mit der Stapelgröße für den Prozess zusammenhängt.

Die Liste der lokalen Variablen wird in derselben Reihenfolge wie in 4D sortiert, d.h. in der Reihenfolge Datenbankmethode, Projektmethode, Trigger (Tabellenmethode), Formularmethode und Objektmethode.

Die Liste ist in drei Spalten gegliedert:

• Die erste Spalte enthält die Liste der lokalen Variablen, die in Methoden verwendet werden
• Die zweite Spalte enthält die Art der Variablen
• Die dritte Spalte zeigt die Nummer der Dimensionen, wenn die Variable ein Array ist

Am Ende der Datei erscheint die komplette Liste Ihrer Datenbank- und Projektmethoden mit den Datentypen ihrer Parameter und dem zurückgegebenen Ergebnis. Die Information erscheint in folgender Form:

Sie können wählen, ob Sie während dem Kompilieren ein Fehlerdokument erzeugen wollen. Dazu wählen Sie in den Datenbank-Eigenschaften auf der Seite Compiler die Option „Erzeuge Fehlerdokument“ (siehe Optionen zum Kompilieren). Das erzeugte Fehlerdokument erhält den Namen DatenbankName_errors.xml und wird neben der Strukturdatei der Datenbank angelegt.

Die Fehler sind zwar direkt im Compiler-Fenster verfügbar. Ein Fehlerdokument ist jedoch hilfreich, denn es lässt sich leicht auf andere Rechner übertragen, insbesondere wenn mehrere Entwickler in einer Client/Server-Umgebung zusammenarbeiten. Das Fehlerdokument wird im XML Format erstellt, um das automatische Analysieren seines Inhalt zu erleichtern. Damit können Sie auch eigene Formate zum Anzeigen der Fehler erstellen.

Seine Länge richtet sich nach der Anzahl der Fehler und Warnungen, die der Compiler anzeigt. Öffnen Sie das Fehlerdokument über einen Texteditor, könnte es folgendermaßen aussehen:

Das Dokument ist folgendermaßen gegliedert:

• Der Kopfteil zeigt den Namen der Datenbank sowie Datum und Uhrzeit der Erstellung
• Im Bereich ***General errors*** werden alle Typisierungsprobleme und nicht eindeutige Zuordnungen aufgelistet. Diese Fehler und Warnungen enthalten folgende Elemente:
  
  • Erstens, Zeilennummer in der Methode. Allgemeine Fehler haben die Nummer 0 (Null);
  • Status der Warnung: er gibt an, ob es sich um eine Warnung (warning=“true“) bzw. einen Fehler (warning=“false“) handelt;
  • Drittens, Beschreibung des Fehlers, z.B. >Fehlender Parameter in ...<
  Enthält Ihre Datenbank keine allgemeinen Fehler, fällt dieser Teil weg.

Eine Fehlerdatei kann drei Arten von Meldungen enthalten:

• Fehler in einer spezifischen Zeile
• Allgemeine Fehler
• Warnungen

Diese Fehler erscheinen im Kontext, d.h. in der Zeile, wo sie gefunden werden – mit einer Erklärung. Der Compiler meldet diese Art Fehler, wenn er einen Ausdruck findet, in dem eine Inkonsistenz in Bezug auf den Datentyp oder die Syntax vorliegt.

Doppelklicken Sie im Compiler-Fenster auf jeden gefundenen Fehler, um die unmittelbar betroffene Methode im 4D Methodeneditor mit dem in der Zeile hervorgehobenen Fehler zu öffnen.

Die Liste der Syntax- bzw. Typisierungsfehler finden Sie im Handbuch 4D Programmiersprache im Abschnitt Fehlermeldungen.

Treten diese Fehler auf, kann die Datenbank nicht kompiliert werden. Der Compiler meldet in folgenden Fällen einen allgemeinen Fehler:

• Der Datentyp einer Prozessvariablen ließ sich nicht bestimmen
• Zwei unterschiedliche Objektarten haben denselben Namen

Diese Fehler sind allgemein, da sie sich keiner bestimmten Methode zuordnen lassen. Im ersten Fall kann der Compiler keine spezifische Typisierung in der Datenbank durchführen. Im zweiten Fall kann er einen bestimmten Namen nicht eindeutig einem Objekt zuordnen.

Die Liste der allgemeinen Fehler finden Sie im Handbuch 4D Programmiersprache im Abschnitt Fehlermeldungen.

Warnungen sind keine Fehler. Eine Datenbank lässt sich trotz Warnungen kompilieren, sie geben lediglich potentielle Fehlercodes an.

Warnungen erscheinen im Compiler-Fenster in Kursivschrift. Doppelklicken Sie auf jede Warnung, um die unmittelbar betroffene Methode im 4D Methodeneditor mit der in der Zeile hervorgehobenen Warnung zu öffnen.
Die Liste der Warnungen finden Sie im Handbuch 4D Programmiersprache im Abschnitt Warnungen.

Bestimmte Warnungen können Sie auch deaktivieren (siehe Abschnitt Warnungen während dem Kompilieren deaktivieren).

Bereichsprüfung ist standardmäßig in den Datenbank-Eigenschaften markiert. Weitere Informationen dazu finden Sie im Abschnitt Optionen zum Kompilieren). 

Hier ein Beispiel: Nehmen wir an, Sie haben das Array MeinArray als Text deklariert. Die Anzahl der Elemente in MeinArray variiert je nach der aktuellen Methode. Um den Wert „Hallo“ dem Element 5 von MeinArray zuzuordnen, schreiben Sie:

Hat das Array zu dieser Zeit fünf oder mehr Elemente, ist alles in Ordnung. Die Zuweisung erfolgt ganz normal. Hat MeinArray dagegen zu diesem Zeitpunkt weniger als fünf Elemente, macht Ihre Zuweisung keinen Sinn.

Solch eine Situation lässt sich beim Kompilieren nicht feststellen, da davon ausgegangen wird, dass die Methoden ausgeführt werden. Der Compiler kennt nicht die Umstände, unter denen diese Methode aufgerufen wird. Nur über die Bereichsprüfung können Sie überwachen, was gerade passiert, wenn die Datenbank läuft. Im obigen Beispiel würde der Compiler einen Fehler bei der Ausführung innerhalb von 4D melden. In diesem Fall ist die Bereichsprüfung eine wertvolle Hilfe beim Arbeiten mit Arrays, Zeigern und Zeichenketten.

Fordern Sie die Bereichsprüfung an, erscheinen die vom Compiler gesendeten Meldungen in einem spezifischen Fehler-Dialogfenster. Weitere Informationen finden Sie im Handbuch 4D Programmiersprache im Abschnitt Meldung bei Bereichsprüfung.

Ist die Bereichsprüfung aktiviert, wollen Sie diese in manchen Fällen auf bestimmte Teile des Code, die zuverlässig arbeiten, nicht anwenden. Das gilt insbesondere für Schleifen, die viele Male wiederholt werden. Hier kann die Bereichsprüfung die Bearbeitung signifikant verlangsamen, wenn die kompilierte Datenbank auf älteren Rechnern läuft. Sind Sie sicher, dass der betreffende Code korrekt ist und keine Systemfehler verursacht, können Sie die Bereichsprüfung für diese Teile des Codes deaktivieren.

Dazu versehen Sie den entsprechenden Code mit den Kommentaren //%R- und //%R+. //%R- deaktiviert die Bereichsprüfung, //%R+ aktiviert sie wieder:

Hinweis: Diese Operation funktioniert nur, wenn die Bereichsprüfung aktiviert ist.

Nehmen wir an, Sie stoßen beim Laufen der Datenbank auf Unregelmäßigkeiten. Ehe Sie über die Ursachen dafür spekulieren, sollten Sie die vom Compiler angebotene Unterstützung nutzen. 

Es gibt verschiedene Möglichkeiten:

• 4D zeigt seine eigenen Fehlermeldungen an.
  Korrigieren Sie Ihre Datenbanken, soweit möglich, gemäß den Anweisungen von 4D. Sind sie zu allgemein, kompilieren Sie Ihre Datenbank erneut, vergewissern Sie sich, dass die Option Bereichsprüfung aktiviert ist. Testen Sie Ihre Datenbank erneut. Dort, wo anfangs die Fehlermeldung erschienen ist, setzt der Compiler eine Meldung mit weiteren Informationen.
• Ihre kompilierte Datenbank arbeitet anders als die interpretierte Datenbank. Sehen Sie sich die Warnungen genauer an.
• Variablen vom Typ Zahl oder String geben nicht die erwarteten Werte zurück. Überprüfen Sie in den Einstellungen der Datenbank die standardmäßig definierten Optionen zur Typisierung und prüfen Sie in der Symboldatei, ob all Ihre Variablen korrekt typisiert sind.
• Ihre Datenbank funktioniert im interpretierten Modus, im kompilierten Modus stürzt sie ab. Stellen Sie sicher, dass die Datenbank mit der Option Bereichsprüfung kompiliert wurde und überprüfen Sie, ob die kompilierte Datenbank dieselben Plug-Ins verwendet, wie während dem Kompilieren.