Microsoft® Access® rechnet falsch: richtig heftiger Fehler gefunden!

Immer wieder haben wir an dieser Stelle über Softwarefehler berichtet, so zum Beispiel über die Microsoft-Null oder darüber, wie Microsoft® Project® Projektpläne verhackstückt. Jetzt wurde in Microsoft® Access® ein richtig heftiger Fehler gefunden: Daten aus der Druckvorschau verändern sich im Papierausdruck, ohne erneut berechnet zu werden. Alle Papierausdrucke enthalten damit unter Umständen Fehler, die am Bildschirm unsichtbar sind. Der Fehler tritt in Access® 2000, XP und 2003 auf. Autsch!

Ein Bericht dient dazu, Daten aus der Datenbank in druckfähiger Form zu präsentieren. Diese Daten können direkt aus einer Tabelle stammen, oder erst beim Erstellen des Berichts von VisualBASIC berechnet werden. Letzteres ist insbesondere nützlich, um Summen oder andere Ergebnisse unter den Bericht zu schreiben. Dieser Bericht beispielsweise enthält Monatssummen, die aus einer Tabelle stammen, und darunter eine ausgerechnete Summe:

Die vorstehende Druckvorschau dient dabei der Vorabkontrolle. Der Nutzer kann sich die Daten ansehen und entscheiden, ob er das wirklich ausdrucken will. Druckt der Anwender aber diese Tabelle aus, so sieht die Summenzeile seines auf Papier (oder als PDF) gedruckten Berichtes so aus:

Wer sich jetzt darüber wundert, weshalb die Summen sich auf einmal verdoppelt haben, erlebt eine weitere Überraschung, wenn er etwa ein PDF oder ein FinePrint-Dokument gedruckt hat, und sich danach erneut die (ja immer noch offene) Druckvorschau ansieht:

Richtig, die Daten haben sich erneut verändert - und sind noch verkehrter als zuvor: und das, ohne daß die Druckvorschau geschlossen wurde. Wer das nicht glaubt, sollte es jetzt zunächst mit Access® 2000, XP oder 2003 mit dieser Beispieldatei ausprobieren.

An der Software, die die Tabelle erstellt, kann es nicht liegen, weil sie im Beispiel entfernt wurde - die Tabelle enthält nur Konstanten. Auch an der Berechnung der Summen kann es nicht liegen, denn die ist in der ersten Druckvorschau ja offensichtlich richtig. Zudem wird das Sub

Private Sub Berichtsfuß_Print(Cancel As Integer, PrintCount As Integer)

nur ein einziges Mal durchlaufen. Davon kann man sich überzeugen, indem man darin einen Haltepunkt setzt: Access hält nur ein einziges Mal an. Zudem entsteht der gleiche Fehler, wenn das Sub

Private Sub Berichtsfuß_Format(Cancel As Integer, FormatCount As Integer)

lautet, also an das Format-Ereignis gekoppelt ist. Der Fehler wird sogar beobachtet, wenn gar kein Berichtsfuß im Spiel ist, sondern sämtliche Werte des Berichts von VisualBASIC berechnet werden: dann ist oft die letzte berechnete Zahl im Ausdruck falsch, alles sonst ist aber korrekt.

Meistens, jedenfalls: wir können hier nämlich den Fehler nicht auf allen Computern reproduzieren. Er scheint also nur manchmal aufzutreten - weshalb und unter welcher Bedingung, ist unbekannt. Nur wo es passiert, passiert es wiederholbar immer; wo es nicht passiert, passiert es anscheinend nie.

Es gibt Fehler, die sitzen im Computer, und solche, die sitzen davor. Hier ändern sich ursprünglich korrekt berechnete Werte durch den Aufruf der Druckfunktion - und sogar die Vorschau ändert sich, wenn sie erneut auf dem Bildschirm dargestellt werden muß, etwa weil ein Zwischendruckertreiber wie der FinePrint-Dispatcher (nicht aber der Adobe Distiller) zwischenzeitlich aktiv und im Vordergrund sichtbar war. Wir haben es also offenbar mit einem Fehler zu tun, der im Computer sitzt. Ob Microsoft® das zur Kenntnis nimmt, und eine Korrektur anbietet, ist indes ungewiß.

Übrigens verdoppeln sich die Beispielzahlen nur unter Access® 2003: probieren Sie das mal mit Access® 2000 aus... :-(

Update 1: Binnen Stunden wurden wir auf eine Lösung für dieses Problem aufmerksam gemacht (danke, Kai!), die darin besteht, eine Summenformel in die ungebundenen Felder im Berichtsfuß zu schreiben und das Berichtsfuß-Sub zu entfernen. Das löst zwar das Problem, aber leider nur in dieser Inkarnation: Der Fehler als solcher besteht fort. In Kalkulationen, Bilanzen, GuV-Rechnungen und ähnlichen Auswertungen müssen nämlich kompliziertere Operationen ausgeführt werden oder nur Zwischensummen aber keine Einzelsalden addiert werden - und das geht oft nur per VisualBASIC. Womit wir wieder wären, wo wir angefangen haben... :-(

Update 2: Ein weiterer Leser, dem ich hiermit recht herzlich danke, weist auf die folgende Lösung des Problems hin, die darin besteht, die im Berichtsfuß benutzten Variablen vorher im Berichtskopf zusätzlich auf null zu setzen:

Private Sub Berichtskopf_Print(Cancel As Integer, PrintCount As Integer)
SummeGesamtA = 0
SummeGesamtE = 0
End Sub

Dies löst das Problem aber ebenfalls nur für die hier gezeigte (einfache) Fehlerdemonstration; wenn alle Berechnungen ausschließlich im Detailbereich des Berichtes stattfinden, dann ist im Ausdruck oft die letzte Zahl oder Zahlenreihe falsch, obwohl sie in der Druckvorschau korrekt war, also richtig berechnet wurde. Hier hilft vorheriges Nullsetzen nicht (jedenfalls habe ich in vielen Experimenten keine Lösung gefunden). Wir scheinen der Sache aber immerhin näher zu kommen... Vielen Dank also allen Lesern, die sich dieser Sache angenommen haben!

Links zum Thema: Tabellenkalkulation: Was ist eine Microsoft-Null? | Schlappe Leistung: Wie Microsoft® Project® Projektpläne verhackstückt (interne Links)