"Datev Framework Library" - zickige Diva, Aladins Wunderlampe oder Büchse der Pandora ?

[#1]

Hallo Community,

normalerweise habe ich (seit langer Zeit) nie direkt etwas mit der "Datev Framework Library" (DFL) zu tun.

Sie wird eben im Zug der Plattforminstallation quasi automatisch mitinstalliert.

Ganz aktuell hatte ich jetzt aber schon mehrere seltsame und mysteriöse Effekte aus dieser Ecke.

In mehreren Datev-Anwendungen (Rechnungswesen, Steuerprogramme, Eigenorganisation) oder sogar gleich beim Starten des Datev-Arbeitsplatzes tauchten DFL-Fehlermeldungen auf, die die jeweilige Mitarbeiterin am Weiterarbeiten hinderte.

Sogar eine Reparatur-Installation der kompletten "Datev Framework Library" und der "Datev Framework Library Services" (von der DVD 13.0) konnte den Fehler nicht beseitigen.

Nur die gesamte "Reparatur"  der lokalen Datev-Plattform von der DVD 13.0 führte hier zum Ziel.

Mich würde stark interessieren, welche Komponenten der Datev-Plattform oder der Windows-Registry gezielt 'angefasst' bzw. repariert werden müssen, um den Fehler zu beheben.

VG

Michael Vogtsburger

P.S.

Dass es bei der "Datev Framework Library" technisch recht heftig 'zur Sache' geht, kann man an der Liste der Komponenten, die zu diesem Paket gehören, erahnen.

Nachtrag:

der Doppelpost war eine Panne 'made by myself' , ein Mistgriff

[#2]

was sagt denn das Servicetool....?

[#3]

das ServiceTool findet alles ganz prima, keine Fehlermeldungen

Vielleicht wird der Effekt ja mal 'klammheimlich' durch ein Hotfix beseitigt.

Es sind ja momentan wieder einige neue Service-Release und Hotfixe in der 'Pipeline', die einen Kollateral-Nutzen haben könnten

[#4]

Die DFL ist (untechnisch) sozusagen das Betriebssystem der gesamten Datev Anwendungen. Ohne diese Komponente geht gar nichts.

Dass die Fehlermeldungen direkt vom Framework kommen, ist eine Besonderheit der Datev Anwendungen, in anderen Systemen werden solche Meldungen abgefangen und durch Fehlermeldungen ersetzt, die dem Anwender (vielleicht) helfen.

Das bedeutet aber nicht, dass das Framework einen Fehler hat, sondern im Allgemeinen, dass der Programmcode, der das Framework verwendet, in der aktuellen Situation nicht erwartungskonform regiert. Das Framework ist tatsächlich fast nie das Problem.

Wenn man weiß, wie man der Report zu lesen hat, ist der Text ab und an sogar für unwissende hilfreich: Der Report beschreibt zeitlich gesehen rückwärts, was zum Zeitpunkt des Fehlers gerade intern passiert ist, das letzte kommt also zuerst.

Dort stehen meist irgendwelche Komponenten-Namen, die einen auf die richtige Fährte führen.

Viele Grüße von der Küste

[#5]

Ach ja, auf die Frage ob Diva oder Wunderlampe wäre mein Vorschlag "Pedant"

edit: Rechtschreibung

[#6]

Danke Herr Hagena,

das klingt nach Insider-Erfahrungen.

Vielleicht lässt sich der 'Pedant' DFL ja herab, einem Unwissenden Anwender per Fehler-Report einen Hinweis zu geben, wo man weiter nach der Nadel im Heuhaufen stochern könnte.

Vielleicht sind es ja die berühmten "unerwarteten Ausnahme-Fehler" (unattended exception errors) oder so ähnlich, mit denen niemand rechnet, und für die es nur noch den Sprung in`s Nirwana des RAMs gibt.

Ich bin mal gespannt, ob ich ohne Alphabetisierungskurs in Sachen "Lesen eines Fehlerreports" doch noch zum Ziel komme.

Viele Grüße

Michael Vogtsburger

[#7]

Moin Herr Vogtsburger,

die sind es, ich war fünf Jahre Entwickler bei der Datev.

Den Fehler-Report gibt es immer dazu, wenn Sie auf die Schaltfläche "Fehlerbericht" klicken, können Sie diesen einsehen.

Ich hatte gerade eine Exception, anhand derer sei der Aufbau kurz erläutert:

Den obersten Bereich können Sie ignorieren, wenn Sie nicht das Glück einer "sprechenden" Meldung haben so wie ich gerade, da steht direkt "Detail: Der Druckername ist unzulässig."

Ab "| Details" wird es interessant:

ThreadId: 1

ThreadName: DFLMainThread

ExtendedStackTrace:

   bei Datev.Irw.SystemComponents.Reports.Workflow.PrintWorkItem.ExeptionFromPrintService(Exception ex, String appendix)

   bei Datev.Irw.SystemComponents.Reports.Workflow.PrintWorkItem.RunPrintJob(XPathNavigator reportsnavi, Boolean addandrunonlylast)

   bei Datev.Irw.SystemComponents.Reports.Workflow.PrintWorkItem.OnRunStarted()

Das "IRW" bedeutet, dass Rechnungswesen ein Problem gehabt habt, am Ende (bzw. im Text am Anfang) kann man erkennen, dass es etwas mit der Druckaufbereitung (PrintService) zu tun hat, nachdem die letzte Anweisung "RunPrintJob" war.

Damit hat man schon einmal zwei Anhaltspunkte, wer denn hier ein Problem hat. Das besagt noch nichts über das Warum, oder darüber wo der Fehler tatsächlich sitzt. Das muss nicht zwingend etwas mit Rechnungswesen zu tun haben, dies ist aber auch nicht an Ihnen zu klären.

In meinem Fall müsste auf jeden Fall der Service Rechnungswesen anfangen mit der Fehlersuche. Die können (idealerweise) feststellen, warum der Fehler ausgelöst wurde und das Problem dem Zuständigen weiterleiten, der das dann in einer der nächsten Versionen lösen sollte...

[#8]

Hallo Herr Hagena,

ich konnte gestern nochmal die DFL-Fehlermeldungen in verschiedenen Anwendungen reproduzieren.

Aus den Fehlerberichten lässt sich für mich (als Unwissenden) kein System und keine gemeinsame Ursache erkennen. Die Einträge im Fehlerbericht wirken völlig unterschiedlich.

Die Ausnahmefehler sind aber alle ausnahmslos unexpected, unhandled und unschön

Ich bin gespannt, ob ein Datev-Wissender etwas aus dem gesendeten Fehlerbericht herausorakeln kann.

Also ... abwarten und (ostfriesischen) Tee (aus dem hohen Norden) trinken ...

Viele Grüße

Michael Vogtsburger

[#9]

Sie haben hoffentlich einen Servicekontakt mit dem Log im Anhang übermittelt? Bei der "Bericht senden" Variante erhalten Sie grundsätzlich keine persönliche Rückmeldung.

Ausnahmefehler sind immer unschön, über unexpected kann man teilweise streiten

[#10]

Hallo Herr Hagena,

danke für den Hinweis.

Nein, ich hatte keinen ServiceKontakt angelegt, sondern nur Reports gesendet.

Dass man auf solche Einsendungen keine Antwort erhält, war mir nicht bekannt.

Man meldet Fehler und muss dann hoffen, dass sie vielleicht irgendwann einmal analysiert und in einer der nächsten Programmversionen behoben werden ?

Gestern hatte nicht einmal die "Reparatur" der kompletten Client-Datev-Plattform und zusätzlich mehrerer Updates zum Ziel geführt. Das ServiceTool zeigte keine Fehler.

Aber da mir solche Effekte keine Ruhe lassen, bin ich nochmal einer 'Eingebung' gefolgt und habe ein Update von Windows 10-Version 1809 auf 1903 gemacht.

... und siehe da, ich konnte danach die DFL-Fehler in mehreren Anwendungen nicht mehr reproduzieren.

Anscheinend wurden mit dem Windows 10-Update auch die Voraussetzungen für die Lauffähigkeit der "Datev Framework Library" wiederhergestellt.

"Ein blindes Huhn findet auch mal ein Korn"

Viele Grüße

Michael Vogtsburger

[#11]

Aber da mir solche Effekte keine Ruhe lassen, bin ich nochmal einer 'Eingebung' gefolgt und habe ein Update von Windows 10-Version 1809 auf 1903 gemacht.

Hatten Sie das vorher auch gesagt, dass der Rechner nicht auf dem neuesten Stand war, was Windows10 angeht?

[#12]

Das Funktionsupdate  auf 1903 war zwar noch nicht installiert, aber es laufen ja noch einige PCs völlig störungsfrei unter 1809 und die PCs sind unter 1809 'up to date'.

Die Fehler-Ursache lag/liegt aus meiner Sicht nicht an 1809, sondern anscheinend an fehlenden, falschen oder veralteten Systemdateien innerhalb des Betriebssystems oder zentralen Komponenten, vielleicht in DotNet-Framework oder woanders.

Egal. das konnte ich mit Hilfe von Datev ServiceTool nicht erkennen.

Das Funktionsupdate auf 1903 hat das alles wieder hingebogen. Das ist erfreulich !

VG

Michael Vogtsburger

edit: Rechtschreibung

P.S.

... fast wie im Märchen  ("Sieben auf einen Streich")