Auch in der zur Erstveröffentlichung aktuellen Version 9.0.2297 des Sage 100 xRM besteht weiterhin ein kleiner, jedoch folgenschwerer Bug: Die Erstellung eines Stapels für die vorbeugende Wartung scheitert ohne Meldung bei Objekten mit verbrauchszählerabhängigen Wartungsmodalitäten.

Ursache

Ursächlich ist, dass der Defaultwert True des Parameters bForwardOnlyReadOnly bei der Initialisierung des GenericRecordsets einen wahlfreien Zugriff ausschließt. Nach dem Auslesen des aktuellen Zählerstands soll mit rs.MoveLast zum letzten Zählerstand gesprungen werden, um das Delta zu ermitteln. Ein so initialisiertes Recordset unterstützt jedoch nur den sequentiellen Vorwärts-Zugriff.

Codeausschnitt mit der fehlerhaften Initialisierung des GenericRecordsets ohne expliziten Forward-Only-Parameter
Die Ursache im Code: OpenGenericRecordset(sQry) ohne den Parameter, der den wahlfreien Zugriff erlaubt.

Der resultierende Laufzeitfehler wird nicht behandelt, sondern unterdrückt. Sichtbar wird er nur beim Debuggen – die Stapelerstellung bricht stillschweigend ab.

Visual-Basic-Debugger zeigt einen Laufzeitfehler beim Sprung zum letzten Datensatz
Der Laufzeitfehler erscheint nur beim Debuggen, unterbricht aber den Programmfluss.

Lösung

Der Bug ist ein echter Showstopper, die Lösung dafür denkbar einfach. Bezogen auf Version 9.0.2297 ist im Klassenmodul BSCrmObjektStapel in der Prozedur mEvalZaehlerVerbrauch die Zeile 1513 zu ersetzen:

Bisher:

Set rs = goSys.oData.OpenGenericRecordset(sQry)

Korrigiert:

Set rs = goSys.oData.OpenGenericRecordset(sQry, False)

Der zweite Parameter überschreibt den Default und erlaubt damit einen wahlfreien Zugriff auf das Recordset. Das Bugfix in vorausgehenden Versionen erfolgt analog – die Zeilennummer kann allerdings abweichen.

Animation: vorher-nachher-Vergleich der Codezeile mit dem ergänzten Parameter
Eine Zeile, ein zusätzlicher Parameter – und die vorbeugende Wartung läuft wieder durch.

Wie kann ein Bug über mehrere Major-Versionen bestehen?

Nach meiner Analyse besteht der Bug bereits seit Version 8.0 des Sage xRM und geht auf die Umstellung der Datenbankzugriffe aufgrund von Änderungen in der Microsoft Access Runtime zurück. Damit dürfte auch Version 7.0 betroffen sein, was ich mangels Testumgebung allerdings nicht verifizieren konnte.

Vorbeugende Wartung ist eine nützliche und mächtige Funktion – die in der Praxis offenbar nur von wenigen xRM-Anwendern genutzt wird. Die Kombination mit einem individuellen Verbrauchszähler scheint praktisch gar nicht vorzukommen, sonst hätte ein so gravierender Bug längst auffallen müssen.

Offen bleibt für mich die Frage, ob hier ein Informations- bzw. Schulungsdefizit besteht oder ob in Sage-100-Projekten die Abbildung verbrauchsabhängiger Wartungen schlicht keine Anforderung ist. Über ein Meinungsbild würde ich mich freuen.


Hinweis: Der Beitrag dokumentiert den Stand mit Version 9.0.2297. Bei späteren Sage-Releases vor dem Eingriff prüfen, ob Sage den Fix inzwischen selbst übernommen hat.

Kontakt