BITTE helfen Sie uns das LibreOffice Forum zu erhalten!
Ihre Spende wird für die Deckung der laufenden Kosten sowie den Erhalt und Ausbau 🌱 des LibreOffice Forums verwendet.
Herzlichen Dank an Alle, die bisher gespendet haben! Spenden heute: 0 Euro
>DANK IHRER SPENDEN -> KEINE WERBUNG FÜR REGISTRIERTE LIBREOFFICE-FORUM-USER!<
🤗 Als Dankeschön werden Sie im Forum als LO-SUPPORTER gekennzeichnet. 🤗
Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hallo zusammen,
Vorgeschichte (kann übersprungen werden)
Ich möchte für meine MCs gerne einige Einlegeblätter nachdrucken, da diese im Laufe der Zeit verblaßt sind. Sie wurden ursprünglich mit MS-Access 2.0 unter dem in IBMs O/S2 enthaltenen Windows 3.1 erstellt und mit einem Nadeldrucker ausgedruckt. Lang’ ist’s also her.
Die Datenbank wurde schon vor Jahren nach MariaDB migriert und die ursprünglich unter MS-Access erstellten Formulare neu erstellt so das ich die DB mittels LibreOffice Base verwalten kann. Auf Ausdrucke/Berichte habe ich bisher verzichtet, da ich alles was ich bisher benötige, online und zu Hause am Bildschirm darstellen und abrufen kann.
BS/Software:
Debian 12/Bookworm, MariaDB, Libreoffice (von Libreoffice.org, die von Debian hat den Berichtsersteller nicht!). Alles ist auf dem jeweils aktuellen Stand.
Berichtserstellung
Ich habe daher die zu druckenden Einleger mittels Berichtsersteller (Report builder) erstellt und bin auch soweit, das alles was ich haben möchte, mit Ausnahme der einzelnen Titel, fertig habe. Der Aufwand* war übrigens unfassbar, wer es genauer wissen möchte kann sich gerne hier melden, ich werde das dann gerne hier im Forum (oder woanders?) schildern.
Die Aufgabe die ich nicht gelöst bekomme, ist die Integration der Titel (Siehe Muster „Titel1“ bis „Titel3“)
Ich habe verschiedenes ausprobiert, aber leider alles erfolglos. Entweder bekomme ich einen Haufen Einlager mit jeweils nur einem Titel (T1, nächster Aufkleber T2 usw.) oder ohne.
In MS-Access wurde das mit einem Unterbericht gelöst, diese Möglichkeit gibt es aber in LO nicht, für Formulare allerdings schon. Ich könnte mir natürlich ein entsprechendes Formular bauen und dann ausgucken, das müsste man dann aber für jede MC einzeln machen. Da ich aber Ausdrucke für mehrere MCs benötige, ist das keine sinnvolle Alternative. Und ich möchte einfach auch wissen wie es funktioniert um es ggf. anderweitig auch nutzen zu können.
Der Ausdruck (Beschreibung):
Zeile 1: auf der oberen (kurzen) Seite.
Zeilen 2-4: Stirnseite, die Zeilen 2 und 3 werden durch eine Linie getrennt.
Zeilen 5-7: Rückseite, die Teilen 6 und 7 werden durch eine Linie getrennt und unter Zeile 7 erfolgt ein weiterer Trennstrich.
Zeilen 8 ff: hier sollen die Titel mir jeweiliger Spielzeit erscheinen.
Die rechte Seite der Zeilen 3-6 (grau hinterlegt): sind für das Anbringen auf der jeweiligen MC-Seite mittels Tesafilm
Ich wäre dankbar für den einen oder anderen Tipp der zu einer Lösung führen kann.
Gruß
* ein derart mieses Programm ist mir bisher nicht untergekommen, ich halte es für einen professionellen Einsatz absolut ungeeignet! Das gilt sowohl für Windows als auch für die von mir genutzte Linux-Version 24.2.2.2
Vorgeschichte (kann übersprungen werden)
Ich möchte für meine MCs gerne einige Einlegeblätter nachdrucken, da diese im Laufe der Zeit verblaßt sind. Sie wurden ursprünglich mit MS-Access 2.0 unter dem in IBMs O/S2 enthaltenen Windows 3.1 erstellt und mit einem Nadeldrucker ausgedruckt. Lang’ ist’s also her.
Die Datenbank wurde schon vor Jahren nach MariaDB migriert und die ursprünglich unter MS-Access erstellten Formulare neu erstellt so das ich die DB mittels LibreOffice Base verwalten kann. Auf Ausdrucke/Berichte habe ich bisher verzichtet, da ich alles was ich bisher benötige, online und zu Hause am Bildschirm darstellen und abrufen kann.
BS/Software:
Debian 12/Bookworm, MariaDB, Libreoffice (von Libreoffice.org, die von Debian hat den Berichtsersteller nicht!). Alles ist auf dem jeweils aktuellen Stand.
Berichtserstellung
Ich habe daher die zu druckenden Einleger mittels Berichtsersteller (Report builder) erstellt und bin auch soweit, das alles was ich haben möchte, mit Ausnahme der einzelnen Titel, fertig habe. Der Aufwand* war übrigens unfassbar, wer es genauer wissen möchte kann sich gerne hier melden, ich werde das dann gerne hier im Forum (oder woanders?) schildern.
Die Aufgabe die ich nicht gelöst bekomme, ist die Integration der Titel (Siehe Muster „Titel1“ bis „Titel3“)
Ich habe verschiedenes ausprobiert, aber leider alles erfolglos. Entweder bekomme ich einen Haufen Einlager mit jeweils nur einem Titel (T1, nächster Aufkleber T2 usw.) oder ohne.
In MS-Access wurde das mit einem Unterbericht gelöst, diese Möglichkeit gibt es aber in LO nicht, für Formulare allerdings schon. Ich könnte mir natürlich ein entsprechendes Formular bauen und dann ausgucken, das müsste man dann aber für jede MC einzeln machen. Da ich aber Ausdrucke für mehrere MCs benötige, ist das keine sinnvolle Alternative. Und ich möchte einfach auch wissen wie es funktioniert um es ggf. anderweitig auch nutzen zu können.
Der Ausdruck (Beschreibung):
Zeile 1: auf der oberen (kurzen) Seite.
Zeilen 2-4: Stirnseite, die Zeilen 2 und 3 werden durch eine Linie getrennt.
Zeilen 5-7: Rückseite, die Teilen 6 und 7 werden durch eine Linie getrennt und unter Zeile 7 erfolgt ein weiterer Trennstrich.
Zeilen 8 ff: hier sollen die Titel mir jeweiliger Spielzeit erscheinen.
Die rechte Seite der Zeilen 3-6 (grau hinterlegt): sind für das Anbringen auf der jeweiligen MC-Seite mittels Tesafilm
Ich wäre dankbar für den einen oder anderen Tipp der zu einer Lösung führen kann.
Gruß
* ein derart mieses Programm ist mir bisher nicht untergekommen, ich halte es für einen professionellen Einsatz absolut ungeeignet! Das gilt sowohl für Windows als auch für die von mir genutzte Linux-Version 24.2.2.2
- Dateianhänge
-
- Cassetteneinleger ohne Titel.odt
- (19.48 KiB) 128-mal heruntergeladen
Re: Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hast Du Dir das Kapitel "Berichte" des Handbuches herunter4 geladen? Da steht alles drin, was zu diesem Modul von Bedeutung ist.
Du musst für einen Bericht alle Elemente in einer einzigen Ansicht (bewusst: Ansicht, VIEW) haben. Die einzige Ausnahme sind Diagramme. Die erstellen eine Verbindung zu den Daten des Berichts und haben eine andere Datenquelle.
Für Dich gilt also:
Eine Abfrage erstellen, in der eben "Typ", "Länge" usw. in jeder Zeile vorkommen, in der auch einer der Titel zu Aufnahme steht. Das bedeutet, dass in der Ansicht diejenigen Elemente, die Du bisher oben stehen hast, so oft vorkommen, wie "Titel" vorkommen.
Die "Titel" erscheinen im Bericht in der Gruppe "Detail". Alles andere erscheint in einem darüber liegenden Gruppenkopf.
Du hast jetzt leider eine vermutlich nicht zielführende Arbeit gemacht, da es Probleme gibt bei einfachen Kopieren von Elemente aus dem Bereich "Detail" in einen Gruppenkopf.
Ja, der Report Builder ist das schwächste Glied innerhalb von Base. Das liegt auch daran, dass das Ding damals unter OpenOffice noch von Entwicklern eingestielt wurde, aber in der Planung auch mehr Features hatte, als letztlich fertiggestellt wurden. Der Weg bei LibreOffice ist ja eher weg von Java. Gerade der Report Builder ist aber zuerst einmal reines Java. Und da geht niemand ran - seit den Anfängen von LibreOffice. Kleine Korrekturen ja, aber nichts von Bedeutung. Was aber für den Anfang das größte Problem ist: Das Ding stürzt beim Editieren leicht auch einmal ab. Wenn ich damit arbeite, dann speichere ich nach jedem wichtigen Schritt im ReportBuilder und auch noch die Base-Datei selbst ab.
Auf Vergleiche mit MS-Produkten reagiere ich immer etwas allergisch. Zum einen: Bei Access sind bezahlte Entwickler im Hintergrund. Hier gibt es für den ReportBuilder keinen. Zum anderen: Access mag für Daueruser einleuchtend sein. Ich wurde einmal gefragt, ob ich eine DB in Access erstellen könnte. Nach mehreren Tagen sinnlosen Probierens habe ich die Logik der Formularerstellung noch nicht durchschaut und konnte Listenfelder nicht einmal aufklappbar gestalten. Die Bedienkonzepte sind für den, der sie laufend benutzt, vermutlich genauso einfach zu verstehen wie für mich die Bedienkonzepte von Base. Für mich sind aber die Bedienkonzepte von Access ein Rätsel, mit dem ich mich zum Glück nicht zu beschäftigen brauche.
Du musst für einen Bericht alle Elemente in einer einzigen Ansicht (bewusst: Ansicht, VIEW) haben. Die einzige Ausnahme sind Diagramme. Die erstellen eine Verbindung zu den Daten des Berichts und haben eine andere Datenquelle.
Für Dich gilt also:
Eine Abfrage erstellen, in der eben "Typ", "Länge" usw. in jeder Zeile vorkommen, in der auch einer der Titel zu Aufnahme steht. Das bedeutet, dass in der Ansicht diejenigen Elemente, die Du bisher oben stehen hast, so oft vorkommen, wie "Titel" vorkommen.
Die "Titel" erscheinen im Bericht in der Gruppe "Detail". Alles andere erscheint in einem darüber liegenden Gruppenkopf.
Du hast jetzt leider eine vermutlich nicht zielführende Arbeit gemacht, da es Probleme gibt bei einfachen Kopieren von Elemente aus dem Bereich "Detail" in einen Gruppenkopf.
Ja, der Report Builder ist das schwächste Glied innerhalb von Base. Das liegt auch daran, dass das Ding damals unter OpenOffice noch von Entwicklern eingestielt wurde, aber in der Planung auch mehr Features hatte, als letztlich fertiggestellt wurden. Der Weg bei LibreOffice ist ja eher weg von Java. Gerade der Report Builder ist aber zuerst einmal reines Java. Und da geht niemand ran - seit den Anfängen von LibreOffice. Kleine Korrekturen ja, aber nichts von Bedeutung. Was aber für den Anfang das größte Problem ist: Das Ding stürzt beim Editieren leicht auch einmal ab. Wenn ich damit arbeite, dann speichere ich nach jedem wichtigen Schritt im ReportBuilder und auch noch die Base-Datei selbst ab.
Auf Vergleiche mit MS-Produkten reagiere ich immer etwas allergisch. Zum einen: Bei Access sind bezahlte Entwickler im Hintergrund. Hier gibt es für den ReportBuilder keinen. Zum anderen: Access mag für Daueruser einleuchtend sein. Ich wurde einmal gefragt, ob ich eine DB in Access erstellen könnte. Nach mehreren Tagen sinnlosen Probierens habe ich die Logik der Formularerstellung noch nicht durchschaut und konnte Listenfelder nicht einmal aufklappbar gestalten. Die Bedienkonzepte sind für den, der sie laufend benutzt, vermutlich genauso einfach zu verstehen wie für mich die Bedienkonzepte von Base. Für mich sind aber die Bedienkonzepte von Access ein Rätsel, mit dem ich mich zum Glück nicht zu beschäftigen brauche.
https://de.libreoffice.org/get-help/documentation/
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
Re: Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hallo Robert,
erst - zum wiederholten Mal - herzlichen Dank für die schnelle und hilfreiche Antwort!
Ich fange mal bei Deiner Nachricht hinten an. Das Du mit MS auf Kriegsfuß stehst kann ich nachvollziehen, Meine Begeisterung für MS hält sich auch bei mir in sehr engen Grenzen (übrigens "MSN" bedeutete für mich immer "Mit Sicherheit nicht"). Nach meinem Atari, auf dem ich den Vorläufer meiner Datenbank mit "Adimens" (relationale DB) habe ich Mitte der 90er meinen 1. PC gehabt und der lief natürlich auf Windows 3.1. Zu allem Übel gab es noch keine Datenbankanwendung, zumindest habe ich keine gefunden mit der ich klar kam. Als Dann Access von MS kam habe ich es halt verwendet um meine ursprüngliche DB wieder aufgebaut. Ansonsten bin ich rel. schnell von Windows wieder weg zu OS/2, Später dann zu Linux, erst Suse und jetzt Debian.
Soweit zur Historie, jetzt zur aktuelle Situation:
Ich gebe zu das ich das Handbuch nur unzureichend "befragt" habe, was auch die Warnung über die Absturzfreudigkeit des Berichtsgenerators betrifft.
Mittlerweile ist es mir gelungen den Bericht so zu erstellen das er meinen Vorstellungen und den früheren Drucken entspricht, aber leider nur mit Titeln einer MC-Seite, entweder Seite A oder Seite B. Damit ist für mich das Problem des eigentlichen Berichtes gelöst. Wenn die Abfrage stimmt wird der Bericht auch funktionieren. Die Übertragung des bisherigen Detailbereiches in den Berichtskopf hat gut funktioniert, es waren nur 2 Versuche nötig.
Woran ich im Augenblick noch scheitere ist die Abfrage so zu schreiben das 1. beide MS-Seiten mit Titeln und auch den richtigen (Beispiel: MC mit Seite A Interpret "Müller", Album "Fritz" Titel 1-12, Seite B Interpret/Album wie Seite A, Titel 13-20).
in der GUI bekomme ich es nicht hin, ich denke ich werde am Besten in der MariaDB mit SQL eine Sicht (View) erstellen die das benötigte Ergebnis bringt.
Ich werde darüber berichten.
Gruß
Christian
erst - zum wiederholten Mal - herzlichen Dank für die schnelle und hilfreiche Antwort!
Ich fange mal bei Deiner Nachricht hinten an. Das Du mit MS auf Kriegsfuß stehst kann ich nachvollziehen, Meine Begeisterung für MS hält sich auch bei mir in sehr engen Grenzen (übrigens "MSN" bedeutete für mich immer "Mit Sicherheit nicht"). Nach meinem Atari, auf dem ich den Vorläufer meiner Datenbank mit "Adimens" (relationale DB) habe ich Mitte der 90er meinen 1. PC gehabt und der lief natürlich auf Windows 3.1. Zu allem Übel gab es noch keine Datenbankanwendung, zumindest habe ich keine gefunden mit der ich klar kam. Als Dann Access von MS kam habe ich es halt verwendet um meine ursprüngliche DB wieder aufgebaut. Ansonsten bin ich rel. schnell von Windows wieder weg zu OS/2, Später dann zu Linux, erst Suse und jetzt Debian.
Soweit zur Historie, jetzt zur aktuelle Situation:
Ich gebe zu das ich das Handbuch nur unzureichend "befragt" habe, was auch die Warnung über die Absturzfreudigkeit des Berichtsgenerators betrifft.
Mittlerweile ist es mir gelungen den Bericht so zu erstellen das er meinen Vorstellungen und den früheren Drucken entspricht, aber leider nur mit Titeln einer MC-Seite, entweder Seite A oder Seite B. Damit ist für mich das Problem des eigentlichen Berichtes gelöst. Wenn die Abfrage stimmt wird der Bericht auch funktionieren. Die Übertragung des bisherigen Detailbereiches in den Berichtskopf hat gut funktioniert, es waren nur 2 Versuche nötig.
Woran ich im Augenblick noch scheitere ist die Abfrage so zu schreiben das 1. beide MS-Seiten mit Titeln und auch den richtigen (Beispiel: MC mit Seite A Interpret "Müller", Album "Fritz" Titel 1-12, Seite B Interpret/Album wie Seite A, Titel 13-20).
in der GUI bekomme ich es nicht hin, ich denke ich werde am Besten in der MariaDB mit SQL eine Sicht (View) erstellen die das benötigte Ergebnis bringt.
Ich werde darüber berichten.
Gruß
Christian
Re: Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hallo Christian,
ich blicke nicht so ganz durch, was Du jetzt mit den A-Seiten und den B-Seiten für ein Problem hast. Aber vielleicht hilft Dir ja eine zusätzliche Gruppe, so dass immer die B-Seite hinter der A-Seite erscheint. Du kannst ja die Gruppierungen verschachteln, so dass eine Sortierung nach A und B erfolgt.
ich blicke nicht so ganz durch, was Du jetzt mit den A-Seiten und den B-Seiten für ein Problem hast. Aber vielleicht hilft Dir ja eine zusätzliche Gruppe, so dass immer die B-Seite hinter der A-Seite erscheint. Du kannst ja die Gruppierungen verschachteln, so dass eine Sortierung nach A und B erfolgt.
https://de.libreoffice.org/get-help/documentation/
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
Re: Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hallo,
nachdem mein Rechner komplett abgestürzt ist – auf dem auch die zu bearbeitende DB-Datei ausnahmsweise nicht auf dem Server sondern lokal abgespeichert war – und ich ihn wieder neu aufsetzen musste, habe ich den Bericht nun fertig. Grundsätzlich funktioniert er, aber leider gibt es noch ein paar ungelöste Probleme:
Wenn in einem zu erstellenden Bericht nur Daten für eine Kassettenseite vorhanden sind, wird der Bericht mit mehreren Kassetten ohne diese Kassette erstellt.
Wenn die Anzahl der Titel für die Kassettenseiten unterschiedlich sind, werden nur so viele Titel ausgegeben wie die Seite mit der geringsten Anzahl Titel hat.
Wenn ein Album über mehrere Seiten oder gar Kassetten, werden in allen Kassetten/-Seiten alle Titel ausgeworfen. Wenn ich versuche das Feld „CASSETTEN.VON TITEL A-SEITE“ (Titelnummern) zu verknüpfen gibt LO die folgende Fehlermeldung aus:
„Unknown column 'CASSETTEN.VON TITEL A_SEITE' in 'where clause' at /home/buildslave/source/libo-core/connectivity/source/drivers/mysqlc/mysqlc_general.cxx:120“
Oder
„Das angegebene Kriterium kann nicht mit diesem Feld verglichen werden.“
Ich habe verschiedene Schreibweisen ausprobiert, keine hat funktioniert
In der Titelliste werden Titel die nicht in eine Zeile passen gekürzt. Wenn anwachsen des Feldes auf „ja“ steht werden alle Titelfelder 2-zeilig ausgeworfen, selbst bei Kassetten die keinen solchen Titel beinhalten.
Die drei erstgenannten Fehler ist die Abfrage nach der der Bericht erstellt wird der Grund, bei dem letztgenannten ist meines Erachtens der Bericht die Ursache.
Zu allem Übel waren die in der Tabelle „CASSETTEN“ die LP-Nummern falsch und ich musste sie manuell anpassen weil eine Aktualisierungsabfrage immer dieselben LP-Nummern in alle Datensätze geschrieben würden. Quelle für die richtigen LP-Nummern ist die in der Tabelle „MUSIK“ angegebene MC-Nummer (Feld „MEDIUM“) und MC-Seite, aber es hat nicht …
Und dann gibt es noch Ungenauigkeiten: eine senkrechte Linie die ich z. B. Im Gruppenkopf bei 11,85cm von links habe und diese im Detailbereich weiterführen will, muß ich in letzterem auf 11,72cm setzen. Das sieht dann in der Bearbeitungssicht falsch aus, das Ergebnis stimmt aber (am Bildschirm). Dann werden Datenfelder mit identischer Höhe und/oder Breite unterschiedlich dargestellt. Einen Vergrößerungsmodus fehlt mir leider ebenso ...
@Robert,
Die Idee die Titel beider Seiten hintereinander zu bringen finde ich nicht so prickelnd weil das
zu meinen vorhandenen Einlegern nicht passt (ich will ja nur einen relativ kleinen Teil neu machen)
und der Papierbedarf dann auch höher (ich schätze mal ca. 30%) ist.
Gruß
Christian
Ich habe mal einen fertigen Einleger als Anhang mitgeschickt.
nachdem mein Rechner komplett abgestürzt ist – auf dem auch die zu bearbeitende DB-Datei ausnahmsweise nicht auf dem Server sondern lokal abgespeichert war – und ich ihn wieder neu aufsetzen musste, habe ich den Bericht nun fertig. Grundsätzlich funktioniert er, aber leider gibt es noch ein paar ungelöste Probleme:
Wenn in einem zu erstellenden Bericht nur Daten für eine Kassettenseite vorhanden sind, wird der Bericht mit mehreren Kassetten ohne diese Kassette erstellt.
Wenn die Anzahl der Titel für die Kassettenseiten unterschiedlich sind, werden nur so viele Titel ausgegeben wie die Seite mit der geringsten Anzahl Titel hat.
Wenn ein Album über mehrere Seiten oder gar Kassetten, werden in allen Kassetten/-Seiten alle Titel ausgeworfen. Wenn ich versuche das Feld „CASSETTEN.VON TITEL A-SEITE“ (Titelnummern) zu verknüpfen gibt LO die folgende Fehlermeldung aus:
„Unknown column 'CASSETTEN.VON TITEL A_SEITE' in 'where clause' at /home/buildslave/source/libo-core/connectivity/source/drivers/mysqlc/mysqlc_general.cxx:120“
Oder
„Das angegebene Kriterium kann nicht mit diesem Feld verglichen werden.“
Ich habe verschiedene Schreibweisen ausprobiert, keine hat funktioniert
In der Titelliste werden Titel die nicht in eine Zeile passen gekürzt. Wenn anwachsen des Feldes auf „ja“ steht werden alle Titelfelder 2-zeilig ausgeworfen, selbst bei Kassetten die keinen solchen Titel beinhalten.
Die drei erstgenannten Fehler ist die Abfrage nach der der Bericht erstellt wird der Grund, bei dem letztgenannten ist meines Erachtens der Bericht die Ursache.
Zu allem Übel waren die in der Tabelle „CASSETTEN“ die LP-Nummern falsch und ich musste sie manuell anpassen weil eine Aktualisierungsabfrage immer dieselben LP-Nummern in alle Datensätze geschrieben würden. Quelle für die richtigen LP-Nummern ist die in der Tabelle „MUSIK“ angegebene MC-Nummer (Feld „MEDIUM“) und MC-Seite, aber es hat nicht …
Und dann gibt es noch Ungenauigkeiten: eine senkrechte Linie die ich z. B. Im Gruppenkopf bei 11,85cm von links habe und diese im Detailbereich weiterführen will, muß ich in letzterem auf 11,72cm setzen. Das sieht dann in der Bearbeitungssicht falsch aus, das Ergebnis stimmt aber (am Bildschirm). Dann werden Datenfelder mit identischer Höhe und/oder Breite unterschiedlich dargestellt. Einen Vergrößerungsmodus fehlt mir leider ebenso ...
@Robert,
Die Idee die Titel beider Seiten hintereinander zu bringen finde ich nicht so prickelnd weil das
zu meinen vorhandenen Einlegern nicht passt (ich will ja nur einen relativ kleinen Teil neu machen)
und der Papierbedarf dann auch höher (ich schätze mal ca. 30%) ist.
Gruß
Christian
Ich habe mal einen fertigen Einleger als Anhang mitgeschickt.
- Dateianhänge
-
- Cassetteneinleger_3.odt
- (22.69 KiB) 56-mal heruntergeladen
Re: Detaildatensätze in Bericht (MC-Einleger mit Einzeltiteln
Hallo Christian,
Du bringst so viele Fragen in einem Post unter, dass es ohne Beispiel äußerst schwierig wird zu antworten.
Spätestens bei einem Punkt in der Datenbankbezeichnung wirst Du gerade mit dem direkten Treiber von LO nach MariaDB auf einen Bug stoßen, der den Inhalt so einer Datenbank für Dich nicht bearbeitbar macht. Der Punkt wird da als Trenner zwischen Datenbank und Tabelle gesehen.
Gruß
Robert
Du bringst so viele Fragen in einem Post unter, dass es ohne Beispiel äußerst schwierig wird zu antworten.
Ich nehme einmal nur das hier: Wie heißt denn nun die Spalte in der Tabelle? "CASSETTEN.VON TITEL A-SEITE" oder "CASSETTEN.VON TITEL A_SEITE"? Und hast Du wirklich in der Spaltenbezeichnung einen Punkt unter gebracht? Ich halte mich da an die alte Regel: Keine Sonderzeichen, als Verbindungszeichen höchstens "_", keine Leerzeichen, aber Groß- und Kleinschreibung sowie entsprechende Maskierung der Namensbezeichnungen. Und: Kurz halten - bei der neuen internen Firebird-Datenbank ist z.B. nach 31 Zeichen Schluss.Wenn ein Album über mehrere Seiten oder gar Kassetten, werden in allen Kassetten/-Seiten alle Titel ausgeworfen. Wenn ich versuche das Feld „CASSETTEN.VON TITEL A-SEITE“ (Titelnummern) zu verknüpfen gibt LO die folgende Fehlermeldung aus:
„Unknown column 'CASSETTEN.VON TITEL A_SEITE' in 'where clause' at /home/buildslave/source/libo-core/connectivity/source/drivers/mysqlc/mysqlc_general.cxx:120“
Spätestens bei einem Punkt in der Datenbankbezeichnung wirst Du gerade mit dem direkten Treiber von LO nach MariaDB auf einen Bug stoßen, der den Inhalt so einer Datenbank für Dich nicht bearbeitbar macht. Der Punkt wird da als Trenner zwischen Datenbank und Tabelle gesehen.
Gruß
Robert
https://de.libreoffice.org/get-help/documentation/
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=base_handbuch
https://www.familiegrosskopf.de/robert/index.php?&Inhalt=xml_formulare
An alle, die das LibreOffice-Forum nutzen:
Bitte beteiligen Sie sich mit 7 Euro pro Monat und helfen uns bei unserem Budget für das Jahr 2024.
Einfach per Kreditkarte oder PayPal.
Als Dankeschön werden Sie im Forum als LO-SUPPORTER gekennzeichnet.
❤️ Vielen lieben Dank für Ihre Unterstützung ❤️