Leere Seiten auf langen kumulierten Listen auf *manchen* PCs (LL22SP4) - erledigt

Deutschsprachiges Forum
1

Hallo allerseits,

ich habe ein merkwürdiges Problem bei der Ausgabe sehr langer Listen, und versuche mal das korrekt zu beschreiben – deshalb so viele Worte:

Mein Programm (Sprache: XBase, List&Label Version 22, SP 4) druckt Abrechnungen, die aus einem Listenteil bestehen (1 bis ca. 600 Seiten) die ein Endblatt mit einer Zusammenfassung haben.
Für den Listenteil und das Endblatt habe ich unterschiedliche Ebenen im Formular eingerichtet, die von einer Bedingung abhängig sind, die das Programm nach Abschluss der Datenübergabe für den Listenteil an List&Label übergibt.
Die Abrechnungen werden zu einer großen Vorschaudatei zusammengesetzt.

Es gibt einen Test- und einen Echtdruck (bei dem u.a. eine Rechnungsnummer vergeben wird.)

Test- und Echtdruck unterscheiden sich:
Beim Testdruck werden alle zu druckenden Abrechnungen in eine kumulierte Vorschaudatei geschrieben werden. (Wird über LlStgsysAppend kumuliert, ggf. sogar in mehrere Vorschaudateien gesplittet und anschließend zusammengesetzt – weil ich früher auf ein Problem gestoßen bin, wenn die Vorschaudateien „zu groß“ werden; die einzelnen .LL-Files werden bis 12 MB groß.)

Beim Echtdruck werden einige der Abrechnungen über List&Label an den E-Mail-Client übergeben und nur die „anderen“ in die Vorschaudatei kumuliert.)
Außerdem wird zusätzlich bei einem weiteren Durchlauf durch die Druck-Methode eine PDF-Datei über List&Label in ein Archivverzeichnis abgelegt.

Das klappt auf meinen Testsystemen (Windows 7 Windows 10 lokal oder mit Server2012-Verbindung) prima (abgesehen davon, dass das Aufrufen der zusammengesetzten Vorschaudatei unglaublich lange dauert: Vorschaudatei 70 MB, ca. 3.700 Seiten auf meinem recht flotten i5-PC mit 16 GB Hauptspeicher fast 30 Minuten!)

Nun zum Problem:
Auf bisher 2 Kundensystemen kam es nur beim endgültigen Druck (mit zusätzlicher Archivkopie und ggf. Versand per E-Mail) dazu, dass die Endblätter (mit der Zusammenfassung, Rechnungsnummer und hinterlegtem PDF-Briefkopf) nach „ein paar“ Abrechnungen leer sind.
Die ersten Abrechnungen sind also vollständig, „irgendwann“ wird statt des Endblatts eine leere Seite ausgegeben.
Ich vermute einen direkten Zusammenhang mit dem E-Mail-Export, allerdings ist das leider nicht eindeutig.
Im aktuellen Fall lief es so:

  1. Abrechnung ca. 600 Seiten, Versand per Mail – OK
  2. Abrechnung 2 Seiten, Ausgabe in Vorschau – OK
  3. Abrechnung 2 Seiten, Versand per Mail – OK
  4. Abrechnung 14 Seiten, Versand per Mail: Endblatt leer
    Bei allen folgenden Abrechnungen ist das Endblatt leer, unabhängig davon, ob der Versand per Mail erfolgt oder in die Vorschau kumuliert wird.

Und wie gesagt: Das Problem scheint vom jeweiligen PC abzuhängen, an dem das Programm läuft.
Betroffen sind 2 PCs in unterschiedlichen Firmen, 1x Windows 7 und 1x Windows 10.
Jedenfalls bei einem Kunden (Win10) tritt das Problem auf dem benachbarten PC (ebenfalls Windows 10) im selben Netzwerk (Server 2008) nicht auf.

Ich wäre sehr dankbar, wenn jemand dazu eine Idee hat.

2

Hallo Kothke,

vielen Dank für Ihren Beitrag.

Anhand der Beschreibung macht es den Anschein als würde der Arbeitsspeicher ausgehen. Denkbar ist, dass dies durch eine zu große Grafik (z.B. Firmenlogo) im PDF-Briefkopf des Endblattes verursacht wird.

Test halber könnten Sie auf dem betroffenen PDF ein anderes PDF probieren bzw. die Größe des PDFs bzw. der Bilder darin optimieren.

Ist es möglich, dass Sie uns die erwähnte 70MB Vorschau-Datei, welche ca. 30min bis zur Anzeige benötigt, über das Supportportal zur Verfügung stellen?

Mit freundlichen Grüßen

Christian Rauchfuß
Technischer Support
combit GmbH

3

Hallo Herr Rauchfuß,
danke für Ihre ANtwort.
Ich habe meinen Kunden gefragt, ob ich die Datei bei Ihnen einreichen darf.
Sie müssten mir auf jeden Fall bestätigen, dass Sie die Daten vertraulich behandeln werden und nach der Analyse löschen.
(Es handelt sich dabei um personenbezogene/vertrauliche Daten - die auch schon vor der neuen DSGVO nicht so ohne Weiteres weitergegeben werden dürfen.)
Ich melde mich, sobald ich eine Antwort habe.
Gruß, Ingo Kothke

4

Hallo Herr Rauchfuß,
das .LL-Dokument ist hochgeladen.
Schönen Gruß,
Ingo Kothke

5

Hallo Herr Rauchfuß,
vielen Dank für den Hinweis auf das sinnlos erstellte Inhaltsverzeichnis, das zum extrem langsamen Öffnen der Preview-Datei führte. Jetzt wird die Datei gefühlt ohne Verzögerung angezeigt. (Die “Ebene im Inhaltsverzeichnis” war tatsächlich nicht bewusst auf “1” gesetzt - keine Ahnung woher das kam.)
Die verwendeten Grafiken habe ich verkleinert und hoffe, dass es bei einem Versuch auf dem Produktivsystem jetzt auch klappt. Für einen Test muss ich meinen Kunden noch überzeugen, dass er den betroffenen PC zur Verfügung stellt.
Vielen Dank und schöne Grüße,
Ingo Kothke

6

Hallo Herr Kothke,

das sind gute Nachrichten. Damit sollte es auch bei Ihrem Kunden funktionieren. Ggf. ließe sich das Verhalten auch in einer virtuellen Umgebung simulieren?

Christian Rauchfuß
Technischer Support
combit GmbH

7

Moin Herr Rauchfuß,
ich werde den Test auf der Hardware des Kunden mit dem PC durchführen, auf dem das Problem auftrat - auf meinen Testumgebungen klappt’s ja immer. Deshalb lieber mit dem Mehraufwand…
Nochmals danke,
Ingo Kothke

8

Moin Herr Rauchfuß,
gestern habe ich den Test durchführen können:
Auf einem anderen PC bei meinem Kunden lief das Programm fehlerfrei durch. Ich gehe jetzt davon aus, dass auf dem PC, auf dem der Fehler auftrat, vielleicht defekten Hauptspeicher hat.
Vielen Dank für den Hinweis auf den Eintrag “Ebene im Inhaltsverzeichnis”. Davon gab es viele sinnlose - wie immer die da mal hineingeraten sind. Die Größe der exportierten PDFs ist durch das Rauswerfen auf ein Drittel geschrumpft.
Der “Fall” ist damit dann erledigt - danke und Gruß,
Ingo Kothke