Temporäre Tabelle(n)

[HeiDieLX]

Hallo zusammen,
in meinem Angebotsprogramm aus der Kombi LibeOffice Base und Postgresql was bislang super funktioniert stellt sich nun das Problem einer Mehrfachbenutzerumgebung.
Konkret:
Es gibt eine Positionstabelle in der die Positionen des Angebots enthalten sind.
Was ist jedoch wenn 2 Anwender zeitgleich ein Angebot erstellen wollen. Es gibt dann eine Mischung der Positionen der beiden Anwender.
Wenn ich nun die Doku richtig verstanden habe sollte “create temporary…” hier die Lösung sein.

Ich habe nun in der Anwendung verschiedene Versuche unternommen, das zu realisieren. Es scheitert jedoch an verschiedenen Effekten.

Die Tabelle im local-Beich ist “gedroppt”. Zum Start der ANG-Bearbeitung lege ich die Tabelle als “temporary” an. Das läuft auch soweit durch.

Beim ersten Insert auf die Tabelle mault das System:

Die Dateninhalte konnten nicht geladen werden. 
/home/abuild/rpmbuild/BUILD/libreoffice-7.2.3.2/connectivity/source/commontools/dbtools.cxx:751
pq_driver: [PGRES_FATAL_ERROR]FEHLER:  Relation »public.hc_angvorpos« existiert nicht
ZEILE 1: SELECT * FROM "public"."hc_angvorpos"
                       ^
 (caused by statement 'SELECT * FROM "public"."hc_angvorpos"') /home/abuild/rpmbuild/BUILD/libreoffice-7.2.3.2/connectivity/source/drivers/postgresql/pq_statement.cxx:262

Der “Select *” oben stammt definitiv nicht aus meinem Code!

Aus den Fehlermeldungen ergeben sich zunächst zwei Fragen für mich.

1. wie kommen ich an die temporäre Tabelle (laut doku wird einen Temporäre Tabelle gleichen Names überladen!?)
2. Die Temporäre Tabelle “lebt” solange die Sitzung aktiv ist. Kann ich in diesem Zusammenhang prüfen ob die Tabelle bereits angelegt ist?

BASIC-Laufzeitfehler.
Es ist eine Ausnahme aufgetreten 
Type: com.sun.star.sdbc.SQLException
Message: pq_driver: [PGRES_FATAL_ERROR]FEHLER:  Relation »hc_angvorpos« existiert bereits
 (caused by statement 'CREATE TEMPORARY TABLE hc_angvorpos (id_apo SERIAL NOT NULL UNIQUE PRIMARY KEY, vid_ako Integer, vid_anschl Integer, vid_anart Integer, vid_augrp Integer, apocalcpos Integer, apobez varchar(40), apobez_2 varchar(50), apobez_3 varchar(40), apobez_4 varchar(40), apoanz numeric(6,2), apoeinheit varchar(10), apoezpreis numeric(8,2), apoberechmod varchar(10), saneu_usr character varying(20) DEFAULT "current_user"());') /home/abuild/rpmbuild/BUILD/libreoffice-7.2.3.2/connectivity/source/drivers/postgresql/pq_statement.cxx:262.

Möglicherweise habe ich das ganze System auch falsch verstanden.
Um Aufhellung bittet
heidielx

[castorp]

@HeiDieLX

Was ist jedoch wenn 2 Anwender zeitgleich ein Angebot erstellen wollen. Es gibt dann eine Mischung der Positionen der beiden Anwender.

Wenn beide am gleichen Angebot arbeiten ist das ja OK, oder?

Wenn sie an verschiedenen Angeboten arbeiten, sollten sich doch die Positionen anhand der ID des Angebots unterscheiden - und dann gibt es auch kein Problem. Generell braucht man keine temporären Tabellen in einer relationalen Tabelle, damit mehr als eine Person damit arbeiten kann.

[HeiDieLX]

@castorp

Generell braucht man keine temporären Tabellen in einer relationalen Tabelle, damit mehr als eine Person damit arbeiten kann.

Hallo,
ich sehe schon ich habe das System nicht tief genug geschildert.

Angebotskopf erstellen (damit erhalte ich die ID) soweit so gut.
Aus der Preisvorgabetabelle die möglichen Positionen je Angebotsart (es gibt 7 verschiedene) mit Null-Menge in die VorPos-Tabelle (hier sollte die temporäre stehen). Hier ist die Ang-ID noch nicht relevant.
Der Anwender bekommt damit nun die Positionen vor selektiert “insert … (select …)” und braucht nur noch die Mengen einzutragen.

Ist er fertig werden die Positionen > Null in die eigentliche Positionstabelle hier nun mit ANG-ID übertragen. D. h. von meinetwegen 20 Positionen bleiben danach lediglich 5 übrig die dann auch auf dem Papier erscheinen. Danach ist der Inhalt der VorPos für eben “diesen” Benutzer nicht mehr wichtig.

Beim nächsten Angebot wird die VorPos “Delete from vorpos” geleert und danach neu befüllt. Weil eben hier ggf. wieder ein ganz anderes Set von Positionen benötigt wird.

Wenn nun hier zwei Benutzer gleichzeitig Angebote erstellen Art 1 und Art 5.
Ich möchte hier halt nicht gar zu viel Programmieraufwand haben bzw. treiben müssen.

[pogomips]

Als erstmal Daumen Hoch für die Nutzung von libre office (statt anderer).
Wenn Du Fehlermeldung bekommst, dass die Temptable nicht vorhanden ist, könnte es 2 Ursachen haben:

• Deine Applikation arbeitet mindestens an dieser Stelle “stateless” ähnlich einem Webserver, als Variante davon, sie arbeitet mit “willkürlichen” Connections, am Bedarf entlang. Wie und ob Libre Office das macht, ist aus meiner Sicht erstmal intransparent.
• Dein Create Statement und er spätere Zugriff divergieren. Also falsches Schema, falsche (fehlende) Rechte zum lesen o.ä.
  Beides kannst Du nachlesen oder wenigstens prüfen.

Ein funktionierendes Stück (PL SQL) Code solltest Du jedenfalls unter Nutzung eines anonymen Blocks hinbekommen. Da sind alle Voraussetzungen für die Erzeugung und Nutzung einer Temp Table gegeben.
Dort also Anlegen und befüllen und abfragen. Das hilft nicht unbedingt für den Ablauf, den Du brauchst, aber für Prüfung der angewendeten Verfahren, Rechte …

Wenn das geht, kann man die Session Frage klären, z.B. aus postgres Sicht, in dem Du Loganweisungen produzierst, die die Session ID seitens PG ausgeben. Sind sie an zwei verschiedenen Code Abschnitten von Libre Office Workflow verschieden, dann hast Du den Fall, den ich oben geschildert habe.

Eine User Differenzierung kannst u.U. “zu Fuß” realisieren, indem Du den User als Unterscheidungsmerkmal in die Daten der Temp Table aufnimmst (Neue Spalte “Creator” oder so).
Das nützt Dir natürlich nur, wenn Du transparent auf die Temptable zugreifen kannst. *

Ansonsten könntest Du diesen Workflow explizit ins Modell aufnehmen und aus der Temptable eine statische machen. Diese muss natürlich als Teil des Workflows immer wieder bereinigt werden, wenn der Workflow gestartet, verwendet, beendet wird oder wenn er abbricht.

• Ich merke gerade, dieser Schritt ist etwas dämlich für eine Temptable, dieses Vorgehen würde man in einer statischen Tabelle wählen. (Auch das kann aber problematisch / unzureichend sein, wenn ein User mehrere Anwendungen öffnen kann)