Estimated reading time: 7 Minuten
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 eine alte Programmiererweisheit sagt: Programming is debugging. Eine andere Weisheit sagt: 90/20 Fehler… Bei 90% der Fehler sitzt der Fehler 20 cm vor der Tastatur… nur: Wie will man solche Dialoge führen?
Programmierer: Das Einzige, was zu dieser Fehlermeldung führen kann, ist, wenn Sie in dem Feld „Menge“ das Wort „Pinguin“ eintippen. Haben Sie das getan?
Anwender: Ich? Niemals!
Wie schön wäre es, könnte man doch nun vielleicht 1 oder 2 Stunden zurücksehen, um festzustellen, was der Anwender nun wirklich an dieser Stelle eingegeben hat…
Navision & Business Central 365 Log-Funktionen
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. Nicht ohne Grund habe ich dazu einen eigenen Artikel geschrieben, der das „Aufräumen in einer Navision-Datenbank“ bzw. das „Bereinigen und verkleinern einer Navision-Datenbank“ näher beschreibt.
–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 („ein Navision Log wird geschrieben“, oder, kürzer: Navision (bzw. Business central 365) Daten werden geloggt).
Ältere Versionen des Logs 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, so wie bei anderen Navision Log Funktionen, namentlich das Changelog.
Navision-Log in einer Textdatei
Sie entscheiden selbst, wann und wo Sie welche Informationen weg schreiben („Loggen“ bzw. in das Navision Log 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 im Navision Log 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 selbst 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 i.d.R. 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. Aber natürlich gilt es auch hier Augenschein zu bewahren: Wenn durch eine Schleife schnell mal 10tausend Logeinträge in die Log Datei geschrieben werden, geht das auch nicht spurlos an der Verarbeitungsgeschwindigkeit vorbei. Wie auch. Log-Einträge kosten, wie jede Datenverarbeitung, auch unter Navision und Business Central 365 am Ende… Zeit!
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 in einer Navision Log Datei überwacht werden.
Und im Navision 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 leicht im Navision Log zu finden!
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.
Einfaches Anzeigen der Navision Log-Datei mit jedem Texteditor
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}“