Serienbrief haengt

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