Serienbrief haengt

de-users
#1

Hallo,
gerade will ich die jährliche Abrechnung als Serienbrief verschicken, da
verhält sich Writer (Linux) ungewohnt: es hängt bei der Erzeugung des
zweiten Briefs als ODF-Dokumente (Namen aus einem Feld). Der erste ging
noch flott, also sofort, beim zweiten ließ Writer sich gefühlt
vielleicht eine Minute Zeit, während der Lüfter laut wurde. Kurz
nachgeschaut: Systemlast 25%, also wird vermutlich einer der vier
Prozessorkerne voll ausgelastet.
Nach dieser gefühlten Minute ging es dann ganz flott weiter, die
restlichen der sieben Briefe waren wieder wie gewohnt schnell erstellt.
Anschließend dasselbe noch einmal mit PDF als Ziele, da ging es dann wie
gewohnt schnell.

Jetzt kommen die anderen dran. Die Quelle ist ein fast identisches
Writer-Dokument und dasselbe Calc-Dokument, andere Tabelle mit 34
Datensätzen. Wieder hängt es beim 2. Brief, wieder mit derselben Last,
diesmal jedoch -diesmal habe ich auf die Uhr geschaut- ist Writer nach
25 Minuten abgestürzt, als ich neugierig das erste erzeugte
Einzeldokument zu öffnen. Es hatte einen Brief fertig und einen zweiten
mit 0 Byte Größe angelegt.

Also habe ich -was man unter Linux sonst nicht macht- einmal neu
gebootet und kein weiteres Programm (außer dem Dateimanager dolphin)
gestartet, um sicher ganz sauber zu sein. Wieder hängt Writer beim
zweiten Serienbriefdokument. Diesmal habe ich brav gewartet und erst
nach einer Stunde abgebrochen. Es waren zwei Serienbriefdokumente fertig
und zwei weitere mit 0 Bytes angelegt. Zusätzlich waren noch zwei
.~lock*-Dateien vorhanden. Daraufhin habe ich alle diese Dokumente
gelöscht und angefangen, die Serienbriefdokumente einzeln zu erzeugen,
indem ich nur jeweils einen Datensatz ausgewählt habe. Das funktioniert
reibungslos, aber das ist so ja nicht Sinn der Sache. Aber sobald ich
mehr als einen Datensatz auswähle, hängt Writer erneut beim zweiten
erzeugten Dokument.

Hat jemand irgendeine Idee, woran das liegen könnte und wie ich der
Sache Herr werde?

#2

Hallo,

Daraufhin habe ich alle diese Dokumente
gelöscht und angefangen, die Serienbriefdokumente einzeln zu erzeugen,
indem ich nur jeweils einen Datensatz ausgewählt habe. Das funktioniert
reibungslos, aber das ist so ja nicht Sinn der Sache. Aber sobald ich
mehr als einen Datensatz auswähle, hängt Writer erneut beim zweiten
erzeugten Dokument.

Nachtrag: wenn PDF-Dokumente erzeugt werden, läuft es anstandslos durch
und braucht dafür -wenn überhaupt- vielleicht ein oder zwei Sekunden.
Aber dann habe ich eben PDF-Dokumente und keine ODTs, die ich aber auch
brauche.

#3

Hallo,

Daraufhin habe ich alle diese Dokumente
gelöscht und angefangen, die Serienbriefdokumente einzeln zu erzeugen,
indem ich nur jeweils einen Datensatz ausgewählt habe. Das funktioniert
reibungslos, aber das ist so ja nicht Sinn der Sache. Aber sobald ich
mehr als einen Datensatz auswähle, hängt Writer erneut beim zweiten
erzeugten Dokument.

Nachtrag: wenn PDF-Dokumente erzeugt werden, läuft es anstandslos durch
und braucht dafür -wenn überhaupt- vielleicht ein oder zwei Sekunden.
Aber dann habe ich eben PDF-Dokumente und keine ODTs, die ich aber auch
brauche.

mittlerweile bin ich geneigt, an einen Bug zu glauben, denn auch mit
anderen Writer-Dokumenten als Serienbrief und anderen Calc-Tabellen als
Datenquelle ist das Verhalten exakt dasselbe. Kann das bitte mal jemand
bei sich verifizieren?

Hier werkelt:
Version: 7.1.1.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 4; OS: Linux 5.11; UI render: GL; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

#4

Hallo Boris,

mittlerweile bin ich geneigt, an einen Bug zu glauben, denn auch mit
anderen Writer-Dokumenten als Serienbrief und anderen Calc-Tabellen als
Datenquelle ist das Verhalten exakt dasselbe. Kann das bitte mal jemand
bei sich verifizieren?

Wenn jemand das verifizieren soll: Stelle so eine Kombination aus
Tabelle, Verbindung und Serienbrief irgendwo ins Netz. Dann ist das für
die Leute, die das nachprüfen sollen, einfach nach zu vollziehen. Das
wird auch für eine Bugmeldung nötig sein: Beispiel so einfach wie
möglich anhängen, damit jedem klar wird: Daran hängt es. Und nach dem,.
was ich bisher von Dir gelesen habe, müsste das ja bereits bei einer
Tabelle mit nur einem Datensatzfeld der Fall sein.

Gruß

Robert

#5

Hallo,

mittlerweile bin ich geneigt, an einen Bug zu glauben, denn auch
mit anderen Writer-Dokumenten als Serienbrief und anderen
Calc-Tabellen als Datenquelle ist das Verhalten exakt dasselbe.
Kann das bitte mal jemand bei sich verifizieren?

Wenn jemand das verifizieren soll: Stelle so eine Kombination aus
Tabelle, Verbindung und Serienbrief irgendwo ins Netz. Dann ist das
für die Leute, die das nachprüfen sollen, einfach nach zu vollziehen.

Die D
Die Daten musste ich wg. Personenbezug erst einmal anonymisieren. Die
Dateien finden sich hier:

<https://kirk.de/LibreOffice/2021-05-13_BK_2020_Vorlage_Wohnungsmieter.odt>
<https://kirk.de/LibreOffice/Wohnungsmieterliste.ods>

Bitte nur und ausschließlich für die Fehleruntersuchung verwenden -Danke.

Das wird auch für eine Bugmeldung nötig sein: Beispiel so einfach
wie möglich anhängen, damit jedem klar wird: Daran hängt es. Und nach
dem,. was ich bisher von Dir gelesen habe, müsste das ja bereits bei
einer Tabelle mit nur einem Datensatzfeld der Fall sein.

Inzwischen habe ich einen Test mit komplett leeren Dokumenten gemacht,
mit gerade mal 11 Feldern (meine produktiven Quellen haben 126 bzw. 187
Spalten, die aber nicht alle als Feld im Serienbriefdokument auftauchen)
-der lief normal durch. Diese habe ich der Vollständigkeit halber auch
abgelegt:

<https://kirk.de/LibreOffice/Test_01.odt>
<https://kirk.de/LibreOffice/Test_01.ods>

(nur zum Vergleich)

Was mir noch auffiel: im Druckdialog für den Serienbrief taucht bei
meinen produktiven Dokumenten ein anderes Tastenkürzel auf: bei

Ausgabe
(_) _D_rucker (o) Da_t_ei

ist das kleine t bei Datei unterstrichen und auch so per Tastenkombi
[Alt]+t erreichbar, bei meinem kleinen Testdokument ist das jedoch nicht
das kleine t, sondern das kleine i:

Ausgabe
(_) _D_rucker (o) Date_i_

Das spielt natürlich keine Rolle, nährt in mir aber den Verdacht, dass
es irgendeinen Unterschied gibt, der sich vielleicht an anderer Stelle
auswirkt.

Momentan "spiele" ich an der Quelltabelle herum, indem ich Formate,
Ansichten und was mir noch so einfällt, ändere, bislang aber noch ohne
Erfolg.

#6

Hallo Boris,

ich habe schnell mal den Test mit Deinen Dateien gemacht und alle 34 Briefe liefen bei mir glatt durch - unter Linux Mageia 8 mit LibO 7.0.4 und unter Windows 10 mit LibO 7.1.3.
Das gilt sowohl für die Erzeugung einer einzigen ODT-Datei als auch einzelner ODT- und PDF-Dokumente - alles problemlos.

Das hilft dir natürlich erst einmal nicht weiter, aber ein Bug in der Serienbrieffunktion scheint das nicht zu sein.

Beste Grüße
Karl

#7

Hallo Boris,

Mit deinen beiden Dateien habe ich unter Xubuntu 20.04 weder mit LO
7.0.5 noch mit LibO 7.1.3 Probleme (Originalversionen von der Website).
Die Serienbrieffunktion spuckt alle .odt-Dateien ohne Verzögerungen aus.

Frage meinerseits: Du müsstest doch noch die *.odb-Datei haben, mit der
du die Daten aus dem Calc-Spreadsheet als Datenbank bereit stellst.
Vielleicht liegt da ein Problem. Die hattest du leider nicht online
gestellt.

Gruß,
Michael

#8

Hallo,

Das hilft dir natürlich erst einmal nicht weiter, aber ein Bug in der
Serienbrieffunktion scheint das nicht zu sein.

ganz so sicher bin ich da noch nicht -es ist zwar nur ein, zwei
hundertstel Versionsnummern weiter, aber vielleicht war es das ja schon.
Ich versuche mal ein Update, muss aber erst ein frisches Backup machen.

#9

Hallo,

Mit deinen beiden Dateien habe ich unter Xubuntu 20.04 weder mit LO
7.0.5 noch mit LibO 7.1.3 Probleme (Originalversionen von der Website).
Die Serienbrieffunktion spuckt alle .odt-Dateien ohne Verzögerungen aus.

das macht mir eine kleine Hoffnung, dass es mit einem Update erledigt
sein könnte. Das probiere ich nach dem obligatorischen Backup mal aus.

Frage meinerseits: Du müsstest doch noch die *.odb-Datei haben, mit der
du die Daten aus dem Calc-Spreadsheet als Datenbank bereit stellst.
Vielleicht liegt da ein Problem. Die hattest du leider nicht online
gestellt.

Das habe ich soeben nachgeholt:

<https://kirk.de/LibreOffice/Wohnungsmieterliste1.odb>

Allerdings wüsste ich mit dieser Datei nichts anzufangen. Den Umweg über
eine .odb-Datei habe ich einfach noch nicht verstanden.

#10

Hallo Boris,

> Frage meinerseits: Du müsstest doch noch die *.odb-Datei haben, mit
> der du die Daten aus dem Calc-Spreadsheet als Datenbank bereit
> stellst. Vielleicht liegt da ein Problem. Die hattest du leider
> nicht online gestellt.

Das habe ich soeben nachgeholt:
> <https://kirk.de/LibreOffice/Wohnungsmieterliste1.odb>

Allerdings wüsste ich mit dieser Datei nichts anzufangen. Den Umweg
über eine .odb-Datei habe ich einfach noch nicht verstanden.

Ist meinem Hang zur Systematik geschuldet :wink: Ich greife lieber auf
eine Datenbank zu, als direkt auf ein Spreadsheet.

Klappt aber auch problemlos mit deiner ODT-Datei.

Noch eine Idee: Greifst du ggf. auf ein Netzwerklaufwerk zu? Damit habe
ich gelegentlich meine Probleme...

Gruß,
Michael

#11

Hallo Boris,

das macht mir eine kleine Hoffnung, dass es mit einem Update
erledigt sein könnte. Das probiere ich nach dem obligatorischen
Backup mal aus.

Frage meinerseits: Du müsstest doch noch die *.odb-Datei haben, mit
der du die Daten aus dem Calc-Spreadsheet als Datenbank bereit
stellst. Vielleicht liegt da ein Problem. Die hattest du leider
nicht online gestellt.

Das habe ich soeben nachgeholt:

<https://kirk.de/LibreOffice/Wohnungsmieterliste1.odb>

Allerdings wüsste ich mit dieser Datei nichts anzufangen. Den Umweg
über eine .odb-Datei habe ich einfach noch nicht verstanden.

Die Textdatei braucht zwingend eine Datenbankdatei, damit sie auf Daten
zugreifen kann. Diese Datei wird im Hintergrund erstellt. Das ist dann
den meisten Leuten gar nicht bewusst.

Ich habe das jetzt hier mit OpenSUSE 15.2 getestet.
Bei LO 7.0.5.2 klappt es mit den Serienbriefen einwandfrei, bei LO
7.1.3.2 hängt die Kiste. Auch bei 7.1.1.2 von OpenSUSE direkt hängt das
Ganze beim 2. Dokument.

Jetzt musst Du einmal schreiben mit welchem Linux Du da dran gehst. Wenn
ich das richtig sehe stammen die Meldungen ohne Bug von den Leuten, die
ein Debianbasiertes System haben, nicht ein System mit rpm-Paketen.

Gruß

Robert

#12

Hallo Boris,

ich habe mir das einmal etwas genauer angesehen. Das ist auf jeden Fall
ein Bug.
Ich erstelle eine Tabelle mit ein paar Spalten. Erst dachte ich, dass
ich viele Spalten bräuchte wie Du - war aber nicht der Fall.
Ich erstelle einen Serienbrief.
Bei dem Serienbrief muss ein Feld auf der Folgeseite sein.
Sobald ich den Serienbrief starte hängt das Ganze bei der Ausgabe des
zweiten Briefes.
Getestet mit 10 Feldern einmal auf einer Seite, einmal mit dem 10. Feld
auf der Folgeseite.

Ich melde das als Bug, vermutlich ja nur für die *.rpm-Linux-Version.
Werden wir ja sehen.

Gruß

Robert

#13

… und hier die Bugbeschreibung:
https://bugs.documentfoundation.org/show_bug.cgi?id=142273

Wäre gut, wenn das jemand bestätigen könnte und auch die Anmerkungen
dazu kämen, dass das wohl in den *.deb-Paketen nicht der Fall ist.

Gruß

Robert

#14

Hallo,

Noch eine Idee: Greifst du ggf. auf ein Netzwerklaufwerk zu? Damit habe
ich gelegentlich meine Probleme...

nein, alles lokal. Bei WLAN gibt es immer wieder mal kurze
Unterbrechungen oder Störungen, weshalb ich mit unison abgleiche, dann
aber lokal arbeite.

#15

Hallo,

Die Textdatei braucht zwingend eine Datenbankdatei, damit sie auf Daten
zugreifen kann. Diese Datei wird im Hintergrund erstellt. Das ist dann
den meisten Leuten gar nicht bewusst.

dass es so ist, habe ich schon mitbekommen, nur: warum es so sein muss,
verstehe ich nicht, und auch nicht, wie es im Detail funktioniert. So
tummeln sich mit der Zeit zahlreiche, längst nicht mehr benötigte
Datenbanken im Angebot, die gerne mal bereinigt werden könnten. Aber da
ich nicht weiß, wie das Ganze funktioniert, lasse ich lieber die Finger
von irgendwelchen Aufräum- oder Löschaktionen.

Ich habe das jetzt hier mit OpenSUSE 15.2 getestet.
Bei LO 7.0.5.2 klappt es mit den Serienbriefen einwandfrei, bei LO
7.1.3.2 hängt die Kiste. Auch bei 7.1.1.2 von OpenSUSE direkt hängt das
Ganze beim 2. Dokument.

Ja, das Update von 7.1.1.2 auf 7.1.3.2 hat auch bei mir keine Änderung
gebracht. Ich würde ja auch auf die Version 7.0.5.2 zurückgehen, wenn
ich herausbekomme, wie ich das tun kann, ohne die rpm-Verwaltung aus dem
Tritt zu bringen.

Jetzt musst Du einmal schreiben mit welchem Linux Du da dran gehst. Wenn
ich das richtig sehe stammen die Meldungen ohne Bug von den Leuten, die
ein Debianbasiertes System haben, nicht ein System mit rpm-Paketen.

Ich nutze OpenSUSE Tumbleweed, also eine rpm-basierte Distribution. Mich
erstaunt, dass es da Unterschiede geben soll, denn wie ich es verstehe,
ist das nur eine unterschiedliche Art, die Pakete zu verpacken, der
Inhalt sollte gleich sein -oder?

#16

Hallo,

Ich erstelle einen Serienbrief.
Bei dem Serienbrief muss ein Feld auf der Folgeseite sein.
Sobald ich den Serienbrief starte hängt das Ganze bei der Ausgabe des
zweiten Briefes.

tatsächlich: ich habe in meinem kurzen Test-Dokument vor dem letzten
Feld einen Seitenumbruch eingefügt, so dass dieses auf der zweiten Seite
landet, und schon habe ich das beklagte Verhalten.

Einerseits beruhigt es mich, weil ich nicht länger nach einem Fehler in
meinen Dokumenten suchen muss; andererseits hemmt es mich in meinem
Arbeitsdrang, weil ich wohl noch eine Weile mit dem Fehler leben muss.

Danke Dir für die Erforschung und die Bugmeldung!

#17

Hallo,

hier getestet unter Windows 10 mit LO 7.1.3.2
keine Probleme...

auch nicht mit einem mehrseitigen Dokument mit mindestens einem Feld auf
einer Folgeseite?

#18

Hallo Boris,

Ja, das Update von 7.1.1.2 auf 7.1.3.2 hat auch bei mir keine Änderung
gebracht. Ich würde ja auch auf die Version 7.0.5.2 zurückgehen, wenn
ich herausbekomme, wie ich das tun kann, ohne die rpm-Verwaltung aus dem
Tritt zu bringen.

Du machst einfach eine lokale Benutzerinstallation.
Lade die 3 Pakte (Programm, Sprache und Hilfe) herunter.
Entpacke die Pakete, so dass Du an die rpm-Päckchen kommst.
Erstelle ein Verzeichnis, in das Du alle rpm-Päckchen schieben willst.
Darin dann noch ein Verzeichnis "install".
Gehe mit Dolphin in das Verzeichnis "install" und starte dort die
Konsole (Terminal).
Der Befehl
for i in ../*.rpm; do rpm2cpio $i | cpio -id; done
macht in dem install-Verzeichnis eine lokale LO-Installation.
Suche die Programmdatei soffice und starte von dort LO.

Ich habe auf diese Art über 20 verschiedene Installationen prallel auf
meinem Rechner. Deswegen kann ich auch alle möglichen Varianten hier
testen.

Gruß

Robert

#19

Nachtrag: wenn man zuerst eine zweite Seite hat und dann versucht, ein
Feld einzufügen, läuft Writer ebenfalls auf Volllast und wird nicht
fertig; es erscheint nicht einmal der Einfügedialog. Dabei spielt es
keine Rolle, wo das Feld eingefügt werden soll; es hilft also nicht, es
auf der ersten Seite einzufügen, etwa um es durch Kopieren auf eine
Folgeseite zu bringen.

Vielleicht hilft das bei der Fehlerjagd.

#20

Hallo Boris,

Nachtrag: wenn man zuerst eine zweite Seite hat und dann versucht, ein
Feld einzufügen, läuft Writer ebenfalls auf Volllast und wird

nicht

fertig; es erscheint nicht einmal der Einfügedialog. Dabei spielt es
keine Rolle, wo das Feld eingefügt werden soll; es hilft also nicht, es
auf der ersten Seite einzufügen, etwa um es durch Kopieren auf eine
Folgeseite zu bringen.

Kannst Du einmal schreiben, wie Du da vorgehst?
Ich habe das folgendermaßen versucht:
Writerdokument geöffnet.
Einfügen → Seitenumbruch
Ansicht → Datenquellen
Tabelle ausgesucht und den Tabellenkopf in das Dokument gezogen - geht
problemlos auf der 2. Seite.

Dann bin ich über Einfügen → Feldbefehl gegangen. Beim ersten Einfügen
auf der 2. Seite klappt das. Beim erneuten Aufrufen kann ich gerade
einmal noch auf "Einfügen" klicken - dann hängt LO.

Meist Du das?

Gruß

Robert