BC Debug: Unterschied zwischen den Versionen

Aus bafbal.de
Zur Navigation springen Zur Suche springen
Zeile 18: Zeile 18:
  
 
Jeder Tab im BAF-Client hat einen korrespondierenden Tab im Debug-Log. Aus Gründen der Performance und der Übersichtlichkeit wird das Log nur geschrieben, wenn es ''Aktiv'' ist. Mit ''Clear Log'' lässt es sich auch löschen. Mit ''StayOnTop'' wird das Formular des Debug-Fensters immer im Vordergrund angezeigt.
 
Jeder Tab im BAF-Client hat einen korrespondierenden Tab im Debug-Log. Aus Gründen der Performance und der Übersichtlichkeit wird das Log nur geschrieben, wenn es ''Aktiv'' ist. Mit ''Clear Log'' lässt es sich auch löschen. Mit ''StayOnTop'' wird das Formular des Debug-Fensters immer im Vordergrund angezeigt.
 +
 +
==Upsert==
 +
 +
Datenänderungen in den Formularen werden intern über so genannte Upsert-Prozeduren an die Datenbank gegeben. Die Prozedur #upsert kann auch aus dem Code heraus aufgerufen werden. Wird das Debug-Fenster ''Upsert'' aktiviert, dann wird vor der Ausführung die Ini-Datei mit den Daten gezeigt (in diesem Format geht das zur weiteren Ausführung). Mittels der beiden Button kann dann entschieden werden, ob die Prozedur ausgeführt werden oder übersprungen werden soll.
 +
 +
[[file:debug upsert.png|800px|Upsert]]
 +
 +
Die eigentlichen Daten werden im Bereich ''[Data]'' dargestellt. Da wir hier eine Datenänderung haben, sehen wir hier nur den Inhalt des geänderten Feldes (hier ''description'') sowie die ID des Datensatzes.
 +
 +
Oben sehen wir den Namen der Tabelle (''t''), den Namen der Schlüssel-Spalte (''k''), ob der Datensatz zu Historisieren ist (die Historisierung selbst erfolgt über Trigger, aber es werden Werte für ''datechg'', ''usrchg'' und ''progchg'' hinzugefügt oder eben nicht). Der Eintrag ''ins'' hat hier den Wert 0, es wird dann daraus ein UPDATE-Statement gemacht, es folgt der Wert für die Schlüsselspalte (''kv'', also ''key value'').
 +
 +
==Select und Exec==

Version vom 1. August 2021, 20:01 Uhr

Die Debug-Tools

Oben links im Developement-Bereich sind die fünf Debug-Tools.

Debug-Log

Das Debug-Log zeigt die einzelnen Prozeduren in der Reihenfolge der Ausführung und die ausgeführten Funktionen inklusive deren Ergebnis an. Im Gegensatz zu einem konventionellen Debugger, bei dem man den Code Schritt für Schritt ausführt, lässt man beim Debug-Log das Programm einfach auf den Fehler laufen und schaut sich dann an, wie es dazu gekommen ist. Das hat sich in der Praxis als deutlich schneller herausgestellt.

Debug-Log

Hier im Beispiel sehen wir oben zunächst noch den Rest einer Funktion, $T(Add_list). Es wird also ein Text übersetzt. Das Ergebnis der Funktion wird nach den vier Minuszeichen angezeigt, Liste hinzufügen, es ist also Deutsch als Sprache eingestellt.

Es folgen ein Label (auch mit einer übersetzten Beschriftung) und ein Edit-Feld, danach wird die Prozedur #filter aufgerufen, welche das Filter-Kommando des Formulars ausführt.

Die Ausführung des Kommandos xlookup_flt beginnt damit, dass der Baum geleert wird. Dann wird geprüft, ob edt1 einen Inhalt hat. An dieser Stelle sind zwei Funktionen ineinander geschachtelt. Zuerst wird die innere Funktion $EDT() ausgeführt, diese gibt einen leeren String zurück. Mit $NEMPTY() wird geprüft, dass der Inhalt von edt1 nicht leer ist - da er leer ist, wird N zurück gegeben.

Es wird also zur nächsten Verzweigung gesprungen, diese ist ohne Bedingung, wird also immer ausgeführt, wenn keine vorherige Bedingung zugetroffen hat. Hier wird mittels eines SQL-Statements der Baum gefüllt.

Jeder Tab im BAF-Client hat einen korrespondierenden Tab im Debug-Log. Aus Gründen der Performance und der Übersichtlichkeit wird das Log nur geschrieben, wenn es Aktiv ist. Mit Clear Log lässt es sich auch löschen. Mit StayOnTop wird das Formular des Debug-Fensters immer im Vordergrund angezeigt.

Upsert

Datenänderungen in den Formularen werden intern über so genannte Upsert-Prozeduren an die Datenbank gegeben. Die Prozedur #upsert kann auch aus dem Code heraus aufgerufen werden. Wird das Debug-Fenster Upsert aktiviert, dann wird vor der Ausführung die Ini-Datei mit den Daten gezeigt (in diesem Format geht das zur weiteren Ausführung). Mittels der beiden Button kann dann entschieden werden, ob die Prozedur ausgeführt werden oder übersprungen werden soll.

Upsert

Die eigentlichen Daten werden im Bereich [Data] dargestellt. Da wir hier eine Datenänderung haben, sehen wir hier nur den Inhalt des geänderten Feldes (hier description) sowie die ID des Datensatzes.

Oben sehen wir den Namen der Tabelle (t), den Namen der Schlüssel-Spalte (k), ob der Datensatz zu Historisieren ist (die Historisierung selbst erfolgt über Trigger, aber es werden Werte für datechg, usrchg und progchg hinzugefügt oder eben nicht). Der Eintrag ins hat hier den Wert 0, es wird dann daraus ein UPDATE-Statement gemacht, es folgt der Wert für die Schlüsselspalte (kv, also key value).

Select und Exec