Massenbearbeitung und neue Objekte einfügen, PostGIS-Fehler

[petershr01]

Wenn mehrere Objekte per 'Copy and Paste' in eine editierbare DB-Tabelle eingefügt werden, und auch wenn ich ein neues Flächenobjekt zeichne, kommt immer unten stehende Fehlermeldung (Beispiel, auch bei den anderen Layern, siehe Bild 1).

_Konnte Änderungen am Layer FP_GruenFlaeche (editierbar) nicht festschreiben

Fehler: FEHLER: 39 Objekte nicht hinzugefügt. Datenanbieterfehler: PostGIS-Fehler beim Attributhinzufügen: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »FP_Gruen_pkey« DETAIL: Schlüssel »(gid)=(2)« existiert bereits. CONTEXT: SQL-Anweisung »INSERT INTO "FP_Landwirtschaft_Wald_und_Gruen"."FP_Gruen"(gid) VALUES(2);« PL/pgSQL-Funktion "XP_Basisobjekte"."child_of_XPObjekt"() Zeile 43 bei EXECUTE

Meine derzeitige Umgehungslösung, bei einem Objekt wird "händisch" die nächst höchste ID eingetragen, dann wird die Einarbeitung gespeichert. Ich weiß, so arbeitet man nicht mit Daten in einer DB.

Ist das Einfügen von Objekten per 'Copy and Paste' generell möglich? Für die Übertragung des derzeitigen Bestandes aus einer ORACLE-DB, ist das aber ein schneller Weg.

Ist ggf. die Datenbank nicht richtig eingerichtet, habe jetzt schon mehrfach die SQL-Dateien für das Anlegen einer XPlan-DB verwendet. Dabei sind auch nie Fehlermeldungen gekommen. Aber die automatische Generierung die 'gid' funktioniert ja scheinbar nicht.

Bild

Vielen Dank für Ihre Bemühungen.

[bstroebl]

Welche QGIS-Version?

[petershr01]

System Windows 10 QGIS 3.16.6 LTR Standalone Installer XPlanung 4.1.0

[petershr01]

Ach ja, XPlanung 5.2

[bstroebl]

Die DB ist grundsätzlich "richtig", ich kann den Fehler hier auch nicht reproduzieren. Grundsätzlich gibt es für alle XP_Objekte nur eine Sequenz aus der die gid erzeugt wird. Diese Sequenz wird immer dann nach einem neuen Wert gefragt, wenn in eine von XP_Objekt abgeleitete Tabelle ein Datensatz eingefügt wird. Dafür ist es unerheblich, ob Sie den Datensatz per Digitalisieren oder per Copy & Paste einfügen. ICh kann es mir nur so erklären, dass Sie in XP_Objekt bereits Datensätze mit gid-Werten haben, die - warum auch immer - nicht aus der Sequenz stammen. Die Aufgabe wäre nun, den höchsten in XP_Objekt vorkommenden gid-Wert abzufragen und den aktuellen Wert der Sequenz "XP_Basisobjekte"."XP_Objekt_gid_seq" auf einen höhreren Wert zu setzen.

[petershr01]

In der DB-Tabelle 'XP_Objekt' sollten doch bestimmt alle Flächenobjekte abgelegt sein, als FP_GruenFlachen, FP_BebauungsFlaeche, FP_VerEntsorgung usw.?

[bstroebl]

Jein, jedes Flächenobjekt hat in XP_Objekt einen verknüpften Eintrag. Die Geometrien liegen aber in der entsprechenden Tabelle selbst.

[petershr01]

Ich frage nur, weil ich eine Differenz habe, in der DB-Tabelle sind 738 Einträge, entspricht den Objekten in FP_BebauungsFlaechen. Alle Flächenobjekt sind aber derzeit 1104, also FP_GruenFlachen, FP_BebauungsFlaeche und FP_VerEntsorgung ?? In der Sequenz "XP_Basisobjekte"."XP_Objekt_gid_seq" steht der höchste Wert auf 4.

[bstroebl]

dann stimmt da was mit den Triggern nicht. Sind Sie der Administrator der Datenbank?

[petershr01]

Jein, ich habe für Testzwecke (XPlanung) PostgreSQL/PostGIS ohne Adminrechte installiert. Habe schon gemerkt das bestimmte Funktionen, z.B. 'Wartung' nicht laufen "'D:\Anwendungen\pgsql\pgAdmin 4\runtime\psql.exe' file not found. Please correct the Binary Path in the Preferences dialog". Das mal als Hintergrundinfo, weiß jetzt nicht wie sich das auf andere Aktionen auswirkt.

[petershr01]

Wobei, pgAdmin4 läuft.

[petershr01]

INFO

[petershr01]

Könnte es eventuell an Objekte liegen, die mal gelöscht wurden. Ich glaube am Anfang habe ich auch mal einige Flächen gelöscht. Nur so eine Idee. Schönen Feierabend.

[bstroebl]

Nein, daran liegt es vermutlich nicht. Es gibt auf jeder Tabelle einen Trigger changeto*, der ruft die Funktion "XP_Basisobjekte"."child_of_XP_Objekt" auf. Der muss laufen, sonst funktioniert die ganze Primärschlüsselgeschichte nicht. D.h. der Nutzer, der die DB einrichtet (die ganzen Skripte ausführt) braucht entsprechende Rechte. Prüfen Sie, ob der Trigger da und aktiviert ist. Beim Debuggen Ihrer Postgres-Installation selbst kann ich Ihnen leider nicht helfen. Zum Testen würde ich sonst immer OSGEO-Live empfehlen. Da ist alles dabei und Sie können sicher sein, dass die DB funktioniert.

[petershr01]

Hier mal die Eigenschaften für die Tabelle FP_BebauungsFlaeche:

Ist das so ok, DELETE steht auf Nein ?

[bstroebl]

sieht erstmal gut aus. Nun wäre zu prüfen, ob der Trigger auch was tut. Stellen Sie den Sequenzwert doch bitte auf z.b 100000, also auf jeden Fall jenseits des Maximalwerts für gid in XP_Objekt und fügen Sie in FP_BebauungsFlaeche ein Feature ein. Was passiert?

[petershr01]

Ok, ich habe den Wert auf 2000 gesetzt, dann zwei Objekte ohne Probleme neu hinzugefügt. Danach Stand der Wert auf 2001:

8 Objekte per 'Copy and Paste' eingefügt, wieder die gleiche Fehlermeldung:

Der 'Zähler' zählt einen zu wenig, oder.

[petershr01]

Die beiden Objekte in der DB-Tabelle:

[petershr01]

Das erste Objekt wird scheinbar immer auf gid=1 eingefügt und das Objekt was zuvor auf gid=1 war überschrieben. Aber scheinbar nur die Geometrie, die Sachdaten bleiben erhalten, siehe hier:

Ich hatte mich immer schon gewundert, das nach dem ich neue Objekte hinzugefügt hatte, in einem immer dieser Text steht obwohl ja noch nichts eingegeben wurde.

[bstroebl]

Irgendwas stimmt da nicht. Er müsste das erste auf 2001 und das zweite auf 2002 einfügen. Welche gid schreibt QGIS jeweils in den Datensatz, bevor Sie die Änderungen 1 und 2 speichern? Kurze Erläuterung zu den Sachdaten: wie ich schon schrieb, hat jeder Datensatz eine Entsprechung in allen Klassen (Tabellen), von denen die konkrete Klasse (Tabelle) abgeleitet ist, für FP_WaldFlaeche also FP_Objekt und XP_Objekt. Wenn Sie nun in FP_WaldFlaeche einen neuen Datensatz mit der gid 1 einfügen (und das können Sie nur, weil mit dem Trigger irgendwas nicht stimmt), dann bezieht er sich auf das Objekt gid=1 in FP_Objekt und XPObjekt. Irgendein anderer Datensatz in irgend einer anderen FP-Tabelle bezieht sich aber auch darauf. Ist also Müll.

[petershr01]

Seltsam, es fehlt aber kein Objekt. Was dann Ihre Erläuterung wohl erklärt. Teste ich mal.

[bstroebl]

Genau, ein Feature in FP_WaldFlaeche und eines in z.B. FP_BebauungsFlaeche haben beide die gid = 1 und beziehen sich damit auf den selben Datensatz in XP_Objekt.

[bstroebl]

Genau solcher Mist soll ja durch den Trigger und die Sequenz verhindert werden.

[petershr01]

Ok, neuer Versuch: gid Wert auf 3000 gesetzt!

3 Objekte per 'Copy and Paste' eingefügt: auf 'Alle einfügen (einschl. ungültigen)' geklickt.

Hier die Tabelle vor dem Speichern:

und hier nach dem Speichern:

[bstroebl]

welches sind denn die neu eingefügten Objekte (gid) in den beiden Tabellen?

[petershr01]

Die 2002,2003 und 3001

[petershr01]

Vier neue Objekte einfügen: Tabelle vor dem Speichern:

Fehlermeldung:

[petershr01]

gid Wert in "XP_Objekt_gid_seq":

[bstroebl]

Also ich verstehe nicht, warum bei Ihnen in den neuen Objekten überhaupt ein gid-Wert eingetragen ist. Machen Sie das per Hand? Macht QGIS das selbständig? Warum aus der Sequenz? Warum überhaupt? Warum ist andererseits auch einmal ein NULL-Wert eingetragen. Ich habe hier bei mir eben getestet, bei mir ist der Wert immer NULL. Das sollte letztendlich aber egal sein, weil der Trigger immer aus der Sequenz einen neuen gid-Wert anfordern sollte.

[petershr01]

ALLGEMEINE INFO: Dieses Verhalten, also das Problem mit der gid beim Einfügen von Objekten, hatte ich auch schon bei meinen ersten Versuch. Diesen habe ich auf meinen privaten Laptop durchgeführt, auf dem QGIS und PostgreSQL/PostGIS schon installiert waren. Damals hatte ich dann die Testdaten importiert, FNP Wilhelmshafen, und habe dann Flächenobjekte vom Import Schemata in die entsprechenden DB's auch kopiert, oder nachgezeichnet.

[petershr01]

Also nein, ich habe keinen gid-Wert per Hand hier, in diesem Test eingetragen. Wie ich in der Beschreibung oben geschrieben habe, hatte ich bei den bis dahin eingefügten Objekte, als "Umgehungslösung" immer bei einem DB-Eintrag, der mit Wer 'NULL', vor dem Speichern die nächst höchste ID händisch eingetragen. Nur so ging bis jetzt das Speichern.

[petershr01]

Vorschlag, es ist derzeit ja nur ein Test, ich lösche die alte komplett und erstelle nochmal eine neu DB für XPlan.

[bstroebl]

Dann schalten Sie in den Layereigenschaften in Attributformular bitte die Einstellung Formular beim Hinzufügen von Objekten verbergen ein. Dann sollten Sie auch mit NULL-Wert speichern können. Oder meinen Sie mit Speichern das Speichern des Layers?

[petershr01]

War es schon:

[petershr01]

Ist vielleicht die Zuordnung der Nutzerrollen hier nicht richtig. Es werden ja XP-User angelegt, muss man da z.B. bei der Einrichtung in QGIS etwas beachten?

[bstroebl]

d.h. Sie können die Änderungen am Layer nicht speichern, wenn da noch ein NULL drinsteht? Was gibt QGIS dann aus?

[petershr01]

Getreu dem Moto, das Problem sitz immer vor dem PC.

[petershr01]

Nein, ich kann nicht speichern weil die Fehlermeldung kommt:

[bstroebl]

es wird zwar AFAIK nicht empfohlen unter postgres zu arbeiten, sollte aber technisch gehen, insbesondere bei einer lokalen DB und Testbetrieb

[bstroebl]

ah, ok, das ist dann der Fehler. Was passiert, wenn Sie alle gids bei den neuen Objekten rauslöschen (also auf NULL setzen)?

[petershr01]

Copy and Paste, in der DB alle gid Werte der vier neuen Objekte auf NULL gesetzt:

gespeichert:

funktioniert!

[petershr01]

[petershr01]

PostgreSQL Version 10.17.-2 PostGIS Version 10-3.1.1

DB Problem??

[petershr01]

Nochmal versucht, Copy and Paste, alle gid-Werte auf 'NULL':

gespeichert:

Vor dem auf NULL setzen waren wieder bis auf einem Eintrag, alle mit einem Wert befüllt.

[petershr01]

Auf jeden Fall erst einmal eine bessere "Umgehungslösung", als händisch die nächste ID zu suchen und einzutragen.

[petershr01]

Bin die nächsten 3 Stunden nicht erreichbar.

[petershr01]

ANFRAGE, NICHT DIREKT DIESES THEMA Darf ich mal nachfragen, wie bei Ihnen der Export ins XPlanung-GML Format erfolgt. Wird eine eigene Lösung verwendet, über Dienstleister oder ein kommerzielles Softwareprodukt zusätzlich genutzt. Wenn ich Sie zu dieser Fragestellung über einen anderen Weg ansprechen soll, bitte mitteilen. Danke.

[bstroebl]

Was das ursprüngliche Thema betrifft: Es scheint also eine Lösung gefunden, es bleiben aber zwei Fragen offen:

1. wie und warum nimmt QGIS Werte aus der Sequenz als gid?
2. warum funktioniert trotzdem der Trigger nicht? Dem sollte es nämlich egal sesin, ob gid NULL oder eine Zahl ist. Zu 2: haben Sie für gid in QGIS oder auf der DB einen Defaultwert vergeben?

[bstroebl]

Antwort aufs andere Thema: Aktuell machen wir keinen Export. Die Frage wird sich aber über kurz oder lang stellen.

[petershr01]

Guten Morgen und danke für die kurze Info zum zweiten Thema, hier steht dieses aktuell im Raum. Zurück zum eigentlichen, ich habe an den Layereigenschaften nichts geändert. Es wurde die DB eingerichtet, ihre beiden Erweiterungen in QGIS installiert und dann ging es los. Hier mal exemplarisch zwei Bilder mit den 'gid' Attributformular Einstellung im QGIS Projekt:

[petershr01]

Und hier mal die Eigenschaften des Triggers: