NAV Logging

Haben Sie sich schon einmal gewünscht, in die Vergangenheit zu sehen? Was bei Fotoalben und Fernsehen das natürlichste auf der Welt ist, ist bei Navision bzw. Business Central fast unmöglich.

Und doch ist es so nötig, und so hilfreich! Denn: Programming is debugging, was sie auch in diesem Werbelink vertiefen können:

Im Allgemeinen haben Sie nur diese Mittel:
–Changelog: Je nach Änderungsfrequenz in den Tabellen knallt Ihnen das Logging über das Änderungsprotokoll schnell ihre Datenbank voll. Längst nicht mehr relevante, 5 Jahre alte Informationen konkurrieren dabei um minütliche Änderungen, z.B. in Verkaufszeilen und Fibu Buchungsblättern. Dazu kommt die Last auf dem Server und in der Datenbank, verbunden mit Tablelockings.
–Geändert am: Die Stammdaten von Navision oder Business Central beinhalten meist das Feld „Geändert am“ (von den meisten Firmen ergänzt um „Geändert von“ und „Angelegt am/von“). Das verrät zwar sehr platzsparend, wann die letzte Änderung an diesem Satz erfolgte, aber nicht welche Änderung.
–Raten. „Wenn jetzt dies drinsteht, dann könnte vorher das dringestanden haben.“
–Datensicherungen. In einer schönen Navision und Business Central Entwicklungsumgebung haben Sie z.B. für jeden Tag des Monats für die letzten 30 Tage eine automatische, jederzeit betriebsbereite Entwicklungsversion vorrätig, in der Sie etwas nachsehen können. Aber auch die verrät nur den Ist-Zustand zum Zeitpunkt der Datensicherung.
–Debugger: Damit können Sie leider immer nur den jetzt gerade aktuellen Zustand von Business Central & Navision recherchieren, und das auch nur mit immensem Zeitaufwand. Selbs wenn Sie sehr genau ahnen, an welcher Stelle der Fehler auftreten könnte oder müsste, so müssen Sie mit dem Debugger in endlos langen Sitzungen rund um kritischen Code immer und immer wieder den gleichen Programmcode bei der Arbeit zusehen. Das ist etwa so produktiv und aufregend wie Farbe beim trocknen zuzusehen.

Die Lösung: Datei-Logging. Dabei wird mit einer generischen, leicht aufzurufenden und immer gleichen Funktion eine von Ihnen festgelegte Information pro Tag/Sitzung in eine Datei geschrieben.
Ältere Versionen werden dabei automatisch gelöscht, so das auch nach Jahren immer nur frische Informationen der jeweils aktuellen Programmstände zur Verfügung stehen.

Da hier keine Konkurrenz der Prozesse entsteht, ist diese Lösung sehr schnell und Lock-frei. Und die Datenbank wird nicht mit 99% unnötigen Informationen zugemüllt.

Sie entscheiden selber wann Sie welche Informationen weg schreiben. z.B. gesetzte Filter, gefundene Sätze, gewählte Sortierungen:

Im Log können Sie sich dann gemütlich, sowohl beim Entwickeln wie auch bei der viel später auftretender Fehlersuche, die komprimierten Ergebnisse ansehen, und müssen dabei nicht mit blutenden Fingern durch den Debugger von Business Central oder durchsteppen:

10:11:45. 67,PAGE 50195,20-FA-10572,Korrekte Spalte suchen,Status=CONST(Released),FA-Nr.=CONST(10572),Arbeitsplanref.-Nr.=CONST(10000),Arbeitsplannr.=CONST(000643),Arbeitsgangnr.=CONST(30)
10:11:45. 67,PAGE 50195,20-FA-10572,Spalte gefunden,201
10:11:45. 67,PAGE 50195,20-FA-10572,Alter Inhalt,0
10:11:45. 83,PAGE 50195,20-FA-10572,Dauer umrechnen,Orig: 50,57 active FAs 1 Worker 2
10:11:45. 86,PAGE 50195,20-FA-10572,Alt Neu Gesamt,0 101,14 101,14
10:11:45. 89,PAGE 50195,20-FA-10572,Zeit aktualisiert,BDE:50 Minuten 34 Sekunden/FA:101,14

Da sich die „Log“ Codeunit selber um
-Neuanlegen der Loggingdatei
-Löschen veralteter Log-Dateien (frei einstellbar)
-Erweitern & formatieren der Log-Datei
kümmert, ist der Aufruf (siehe 1. Screenshot) entsprechend einfach.
Da die Log-datei immer lokal abgelegt wird (so zumindest meine Empfehlung), und am besten noch auf einer SSD oder zumindest RAM-Cache gepuffert, verzögert das Logging nicht den regulären Programmablauf. Typisch ist mit mindestens 15 Logzeilen pro Millisekunde zu rechnen. Ein einziger dadurch gefundener falsch gesetzter Filter/Key rechtfertigt (aus Laufzeitsicht) in der Regel mehrere tausend Logzeilen.

Da die Logfunktion so schnell arbeitet und keinerlei sonstige Seiteneffekte im System oder dem Datenbankserver verursacht, können auch Eingaben, Dateischnittstellen (was kommt? Was geht?), ungewöhnliche Berechnungen (kommt da eigentlich immer das erwartete Ergebnis raus?) etc. problemlos auf Dauer überwacht werden.

Und im Log fällt viel schneller auf, wenn ein erwarteter Programmcode gar nicht durchlaufen wird, oder zu oft, oder in einer nicht optimalen Reihenfolge. Oder Reihenfolgen unerwartete springen, z.B. weil Schlüsselfelder modifiziert wurden. Auch ungewöhnlich lange Laufzeiten (jeder Find mit mehr als 7 ms ist zu lange!) zeigen auf einen Blick falsch gesetzte Filter/Schlüssel/Abfragestrategien. Endlos lange Wiederholungen weißen auf sinnlose Iterationen hin – rein Optisch!

So können auch komplexe Sachverhalte schnell in logische Teilblöcke mit verständlichen Einstiegs- und Ausstiegszuständen aufgeteilt werden.

Dateien, die nicht benötigt werden (Erfahrungsgemäß mehr als 99.9%) verschwinden nach einer Woche wieder automatisch & Rückstandslos.

Wussten Sie schon das Sie im Windows-Dateiexplorer jede beliebige Datei mit Textinhalt in die Textvorschau zwingen können? Standardmäßig werden z.B. Logdateien nicht in der Vorschau angezeigt.

Dafür nötige Änderungen in der Registry. Die erste Änderung ist dafür nötig das Windows jede Datei mit einem Textinhalt überhaupt als Textdatei behandeln kann. Sie ändert noch kein Anzeigeverhalten!

EditFlags steht bereits dort und wird nicht geändert. Die anderen Werte:
[HKEY_CLASSES_ROOT]
@=“Textfile“
„Content Type“=“text/plain“
„PerceivedType“=“text“
„PersistentHandler“=“{5e941d80-bf96-11cd-b579-08002b30bfeb}“

Und, am Beispiel der *.Log-Dateien, die pro als Textdatei anzuzeigende Endung nötigen Erweiterungen der Registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT.log]
@=“txtfile“
„PerceivedType“=“text“
„Content Type“=“text/plain“
[HKEY_CLASSES_ROOT.log\PersistentHandler]
@=“{5e941d80-bf96-11cd-b579-08002b30bfeb}“