Deutsch

Fehlermeldung/Situation

Mögliche Ursache: Nicht geschlossene VBA Sage-Recordsets

Mögliche Ursache: .net CLR Fehler in DCM beim Nachladen von Assemblies führen zu Transaktionsproblemen in Sage ERP

Deutsch

Fehlermeldung/Situation

Mögliche Ursache: Nicht geschlossene VBA Sage-Recordsets

Es wurde irgendwo im Code-Ablauf in Sage VBA/VB6-Recordset nicht korrekt geschlossen.

Dies kann intern das Sage .net-Transaktionsmanagement "durcheinanderbringen" (die VBA/VB6 Sage-Recordset-Klassen sind nur noch interne COM-Wrapper auf die .net-Datenbankzugriffe von Sage).

Es ist zwingend darauf zu achten, dass in VBA/VB6-Methoden alle Sage-Recordsets korrekt geschlossen werden und dass auch korrekte Error-Handler vorhanden sind, die auch im Fehlerfall ein Schließen des Recordsets sicherstellen.

Mögliche Ursache: .net CLR Fehler in DCM beim Nachladen von Assemblies

Auslöser: .net CLR-Fehler in DCM beim Nachladen von Assemblies, die gegen einen anderen Stand von abhängigen Zusatz-Assemblies/Drittanbieter-Bibliotheken compiliert wurden.

Dieser Fehler ist sehr "tricky", da der Fehler indirekt durch Exceptions in DCM-Handler-Code enstehen kann, was nicht beim ersten DCM call zu der Fehlermeldung führen muss!

Diese Exceptions werden von Sage mitunter nicht richtig abgefangen und bringen ebenfalls das Transaktionsmanagement von Sage "durcheinander".

Siehe auch https://www.officium-inservio.com/sage-100-1/dcmnotalwaystriggered.

Wichtig ist generell, dass dynamisch zur Laufzeit nachgeladene Assemblies (z.B. durch DCM-Handler) fehlerfrei durch die CLR geöffnet werden können.

Wenn eine DCM eingesetzt wird, dann wird die jeweilige Assembly, die auf die DCM reagiert, erst dann von Sage in den Prozess geladen, wenn die DCM ausgelöst wird.

Sollten diese Assemblies, die zur Laufzeit von einer DCM ausgelöst werden, irgendwelche Abhängigkeiten zu weiteren Zusatz-Assemblies bzw. Drittanbieter-Bibliotheken haben, z.B. häufig benötigte Routinen in eigenen allgemeinen Assemblies, DevExpress etc., so müssen diese Zusatz-Assemblies in einer kompatiblen Version vorliegen, d.h. die aus Sicht der CLR kompatibel in Bezug auf die Signatur ist.

Anders ausgedrückt: der .net CLR Loader muss die jeweiligen weiteren Assemblies ohne Fehler zur Laufzeit nachladen können, was ausschließlich dann durch den .net CLR Assembly-Loader passiert, wenn die Methoden- und Typensignaturprüfung der CLR nicht zur Laufzeit fehlschlägt.

Wenn die .net CLR beim Laden der Assembly innerhalb der DCM dagegen auf einen Fehler läuft, z.B. weil die vorliegende Version einer Zusatz-Assembly nicht wirklich zur in der DCM geladenen Assembly passt, z.B. veralteter Methodenaufruf, so kann dies den gesamten DCM-Ablauf in eine Exception führen.

Transaktionen bleiben dann offen und beim nächsten Versuch seitens Sage, eine Transaktion zu eröffnen, erscheint o.g. Fehlermeldung.

Wie erklärt wird dieses Problem dadurch ein besonderes, weil der Fehler nicht sofort debugbar beim ersten DCM-Call auftritt, sondern erst später, wenn irgendeine nachfolgende Code-Stelle mit Transaktionen arbeitet.

In neueren Sage 100-Versionen werden DCM-Calls protokolliert (ab Version 8.1 im Sommer 2019 z.B.) und besser durch einzelne Exception-Handler geschützt.

In älteren Sage ERP Versionen findet keine Protokollierung statt, was es besonders schwer macht, das Ganze einzugrenzen!

Sehr häufig kann dieses Problem entstehen, wenn bei der Verteilung von AddOns/Zusatzprogrammierungen und der notwendigen Drittbibliotheken im Netzwerk ein Problem auftritt, z.B. wenn Dateien noch geöffnet sind und nicht ausgetauscht werden können.

Unabhängig davon, ob Dateien über den AppDesigner oder z.B. ein LiveUpdate-Paket verteilt werden, ist es immer möglich, dass nicht alle Dateien ausgetauscht/verteilt werden, so dass ggf. lokal ältere Versionen von Drittanbieter-Bibliotheken/Zusatz-Assemblies vorliegen.

Beide Mechanismen verfügen nicht wirklich über zuverlässiges Fehlermanagement i.S.v. Protokollierung für Administratoren, dass einige Bibliotheken nicht ausgetauscht werden konnten usw.

Verteilungsfehler fallen dann mitunter nicht auf und zur Laufzeit entsteht das hier beschriebene Problem!