Serienbrief haengt

de-users
#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

#21

Hallo Boris,

das ist ein zweiter Bug. Ich habe das ohne irgendeine 2. Seite
nachstellen können. Beim zweiten Versuch, zu dem Einfügedialog zu kommen
hängt LO.
https://bugs.documentfoundation.org/show_bug.cgi?id=142294

Gruß

Robert

#22

Hallo Boris,

> 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.

In der Kurzversion: Du willst ja auf die Tabellen einer Datenbank
zugreifen und hast "nur" eine Calc-Tabelle.

Wenn du auf verschiedenartige Daten_quellen_ zugreifen willst, brauchst
du einen "Adapter", der deinen Programmen den Zugriff auf eine
standardisierte Art bereit stellt. So müssen deine Programme nicht
selber wissen, wie man eine Datenquelle anspricht, die reden nur mit
dem dafür spezialisierten "Adapter".

In LO übernimmt Base diese Funktion.

Ich arbeite immer aktiv mit Base und lege mir die benötigte .odb-Datei
bewuust manuell an, wenn ich Calc-Dateien als Datenquelle nutzen
will/muss.
Die Base-Datei bietet zusätzliche Möglichkeiten: So kann ich z.B.
Abfragen definieren und damit (virtuell) weitere "Tabellen" als Quelle
für z.B. Serienbriefe erzeugen/nutzen.

Ein Beispiel: Einen Freundin von mir hat ein Dokument mit zwei
Tabellen erstellt. Die Personen in Tabelle "Brief" bekommen regelmäßig
einen Info-Brief, die Personen in Tabelle "Paket" bekommen ein Paket
mit Prospekten.

Leider sind manche Personen in beiden Tabellen, so dass sie deren
Adressen bei einer Änderung doppelt pflegen müsste. Zusätzlich wollte
sie weitere Kategorien einführen.

Nun sind _alle_ Personen in einer Gesamttabelle "Empfänger", die sie in
den Seriendrucken auch verwendet. Diese hat jetzt zusätzlich die Spalten
"Brief" und "Paket" bekommen.

In der zugehörigen .odt-Datei sind zwei Abfragen eingebaut: "Briefe"
fischt alle Personen aus der Tabelle, bei denen in der Spalte "Brief"
ein "y" hinterlegt ist. "Pakete" arbeitet analog.

Bei Seriendrucken kann sie jetzt entweder die Tabelle "Empfänger" oder
eine der Abfragen "Pakete" bzw. "Briefe" auswählen, wenn der
betreffende Dokumententyp nur für den entsprechenden Empfängerkreis von
Interesse ist (Packliste, Paketaufkleber,...).
Wenn sie die Tabelle "Empfänger" wählt, kann sie prinzipiell alle
Personen anschreiben, kann aber beim Seriendruck auch noch mal eine
der Abfragen wählen, falls sie diesen Brief nur eine der
Empfängergruppen anschreiben möchte (Portoerhöhung getrennt für
Brief/Paket/beide). Dann braucht sie beim Seriendruck auch nicht
umständlich die zu druckenden Adressen zu markieren.

Der nächste Schritt iun der Evolution: Wir überführen die Calc-Tabelle
in eine echte Datenbank, bevor weitere Kriterien hinzukommen. Dann kann
man bei den Spalten auch den Typ boolean(=j/n) verwenden, statt nach
bestimmten Buchstaben zu filtern.
Dazu muss ich letztlich nur die Tabellen der Calc-Datei in eine
Datenbank übernehmen und die .odt-Datei entsprechend tauschen. Um das
kompakt zu halten, wird das erst einmal eine interne HSQLDB, die in der
ODT-Datei eingebettet ist.

Es lohnt sich also, diesen Zwischenschritt von Datenquelle
(Calc-Datei) über den "Adapter" (Base-Datei) zum Serienbrief bewusst
für sich zu nutzen oder zumindest nicht zu ignorieren.

Schönes Wochenende,
Michael

#23

Hallo,

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.

hier habe ich das Beispieldokument genommen, vor der letzten Zeile (ohne
Feld) einen Seitenumbruch eingefügt, dann ans Ende (also auf die zweite
Seite) gesprungen und versucht, ein Feld einzufügen → hängt.

LO abgeschossen, Dokument neu, Seitenumbruch eingefügt, Versuch des
Einfügens eines Felds auf der ersten Seite → hängt.

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?

So in etwa, ja.

Wenn es beim Serienbriefdruck hängt, kann man nach dem Abbrechen die
Vollast beenden, indem man rechtsmäusig irgendwo in das Dokument klickt.

#24

Hallo,

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.

Danke für den Tipp. Wenn ich das richtig verstehe, werden dabei alle
Paketinformationen wie Abhängigkeiten verworfen. Wenn dem so ist,
funktioniert das wohl mit LibreOffice (zumal wenn es schon in anderer
Version installiert ist), aber nicht unbedingt mit anderen Paketen. Aber
vorliegend hat das mit der Version 7.0.6.2 geklappt, und damit
funktioniert sowohl der Serienbriefdruck nach ODF als auch das Einfügen
neuer Felder. Das nimmt mir schon mal einigen Druck.

Dennoch hoffe ich, dass sich des Fehlers recht bald angenommen wird,
denn es bleibt doch etwas unhandlich, produktiv mit so einer zweiten
lokalen Installation zu hantieren.