Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


Hallo Ulrich,

zu deiner eigentlichen technischen Frage kann ich nichts sagen. Aber mir fallen alternative Möglichkeiten ein, die zwar aufgrund der zwangsläufig vagen Information über dein System nur Denkanstöße und keine Lösungsvorschläge sein können, die ich dir aber trotzdem mitteilen möchte.

Normalerweise würde man bei einem jährlich sich wiederholenden Datenanfall das Jahr in den Schlüssel der betroffenen Tabellen aufnehmen, anstatt getrennte Datenbanken zu erstellen. Das nachträglich umzustellen wäre auch, was die Daten betrifft kein großes Problem, die INSERT-Statements sind schnell erstellt. Schwieriger wäre der Umbau in der Anwendung, da wäre ja das Jahr zusätzlich in irgendeiner Weise zu berücksichtigen. Aber da ja, wie ich jetzt einmal annehme, vornehmlich in einem Jahr gearbeitet wird, könnte man dieses Problem ganz aus der Anwendung herausnehmen, indem man statt auf die Tabellen auf Views (auf Datenbankseite) oder Anfragen (auf LibO-Seite) zugreift, die jeweils die Bedingung für das Jahr enthalten. Views genügen, wenn man eigentlich nicht mehr auf alte Jahre zugreifen muss (man müsste da temporär die View ändern, um auf das Vorjahr zugreifen zu können), Abfragen sind da flexibler, weil man dann mehrere Kopien des Base-Dokuments (.odb) haben könnte, in denen der Satz der Abfragen jeweils ein anderes Jahr enthält. Ich habe den Verdacht, dass Abfragen minimal mehr Aufwand bedeuten als Views, aber das dürfte hier kaum relevant sein. Mit diesen aufs Jahr bezogenen Base-Dokumenten kann man bequem in verschiedenen Jahren arbeiten oder wohl eher auswerten. Selbst notwendige Code-Änderungen, die für vergangene Jahre nicht relevant sind, sind dann bequem machbar, weil der alte Code schon im Jahresdokument gesichert ist. Auch Datenbankänderungen, solange sie nicht zu gravierend sind, dürften sich durch die ABfragen abfangen lassen.

Ob das in deinem Fall etwas hilft, kannst nur du beurteilen.

Gruß

Gerhard

Am 14.11.2019 um 22:52 schrieb Ulrich Goebel:
Hallo,

ich verwende LO Base als Frontend für eine PostgreSQL Datenbank. Dabei liegen die Tabellen in verschiedenen Schemas.


Das Setting:
------------

Ich arbeite in den Formularen viel mit Unterformularen und mit Listenfeldern. Dort muss ich entsprechend qualifizierte Tabellennamen für die Datenquellen usw. angeben, also etwa

schema.tabelle

Soweit, so gut. Aber die Datenbank dient als Personendatenbank für Tagungen, die jährlich stattfinden. Entsprechend heißt es z.B.

tagung_2019.tbl_person

oder

tagung_2020.tbl_person

Bestimmte Daten vererben sich von Jahr zu Jahr, die liegen im Schema public, d.h. es heißt für solche Fälle etwa

public.tbl_laender


Das Problem:
------------

Beim Aufsetzen der DB für das jeweils nächste Jahr müssen nun in allen Formularen und allen Listenfeldern die Schemen-Angaben ersetzt werden. Das ist extrem nervig und vor allem fehleranfällig.


Ein Lösungsansatz:
------------------

In PostgreSQL gibt es für eine Connection den Befehl

set search_path to tagung_2019, public;

Dann werden unqualifizierte Tabellen-Referenzen, also etwa tbl_person erst in tagung_2022, dann in public gesucht.


Meine Frage:
------------

Nun endlich die Frage: Kann man beim Aufrufen der LO-DB dafür sorgen, dass irgendwie der search_path gesetzt wird? Dann könnte ich sämtliche Tabellen-Namen unqualifiziert lassen und müsste für das nächste Jahr nur an dieser einen Stelle den Search-Pfad ändern...

Hat jemand eine Idee?

Ich arbeite mit LO 5.1.6.2 unter Linux mit dem DB Konnektor (PostgreSQL Driver) aus dem Paket libreoffice-sdbc-postgresql. Bei den Datenbankeigenschafte gebe ich bei den erweiterten Einstellungen eine Zeile der Art

host=myserver.xxx port=## dbname=mydb user=myuser

an. Wäre vielleicht an dieser Stelle eine Angabe des Search-Pfad möglich?

Beste Grüße
Ulrich



--
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.