Neuinstallation 3.9.1 - SQL "Operator existiert nicht" bei object_type

Question

Hallo zusammen,

ich betreibe schon sehr lange eine kleine Kivitendo 3.0.0 - Instanz, die zugegebenermaßen leider danach nicht mehr geupdated wurde. Das möchte ich jetzt in Angriff nehmen.

Vorweg habe ich versucht erst einmal eine reine Neuinstallation (also noch ohne Altdatenübernahme) via git durchzuführen - leider stolpere ich dabei aber auch schon. Bis zum Ende des Kapitels 2 klappt soweit alles (Authentifizierungsdatenbank, Mandanten, Benutzer sind also angelegt). Beim Anmelden als Benutzer folgen dann noch Updates an der "Verkehrsdaten"-Datenbank.

Dabei kommte es zu folgender Fehlermeldung:

The database update/creation did not succeed. The file
sql/Pg-upgrade2/file_storage_dunning_invoice.sql containing the
following query failed: UPDATE files SET object_type =
'dunning_invoice' WHERE object_type LIKE 'dunning' The error message
was: FEHLER: Operator existiert nicht: file_object_types ~~ unknown
LINE 1: ...object_type = 'dunning_invoice' WHERE object_type LIKE
'dunn...

                                                         ^ HINT:  Kein Operator stimmt mit dem angegebenen Namen und den Argumenttypen

überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen
hinzufügen. All changes in that file have been reverted.:

Führe ich das SQL-Statemen aus file_storage_dunning_invoice.sql

UPDATE files SET object_type = 'dunning_invoice' WHERE object_type LIKE 'dunning';

direkt gegen posgresql (~adminer oder psql) aus, erhalte ich die gleiche Meldung.

Was hingegen geht (~und auf ein nicht-maskiertes Schlüsselwort hindeuten würde) ist folgendes:

UPDATE files SET object_type = 'dunning_invoice' WHERE 'object_type' LIKE 'dunning';

Habe ich etwas übersehen?
Offenbar scheint das kein allgemeines Problem zu sein, ich habe bisher keine Meldungen dazu gefunden.

Noch ein paar Worte zur Umgebung:
Debian Bookworm 12.8
Apache 2.4.62
Postgresql 15
/scripts/installation_check.pl --> grün

Danke für euer Feedback im Voraus!

Gruß,
MacMac

Answer 1

Moin,

das klingt erstmal nach einem Fehler in der SQL-Syntax, wobei ich mir das eigtl nicht recht vorstellen kann, weil das bei jeder Installation auffallen müsste. Hab es noch nicht nachzuvollziehen versucht, ich sehe nur, dass in meiner Datenbank zu V3.8.0 der Datentyp dieses Felds noch 'text' ist, und da würde der Operator LIKE bzw. diese Abfragesyntax passen.

In meiner Testdatenbank V3.9.1/3.9.2beta ist der Datentyp dieses Felds ein eigener ENUM-Datentyp 'file_object_types', da müsste die Abfrage also anders lauten (für mich als SQL-Laien eher mit IN als mit LIKE).

Dein Vergleich mit dem maskierten Feldnamen macht meiner Ansicht nach nur einen simplen Textvergleich, das würde also nicht den gewünschten Effekt haben.

Welche Version hast Du mit git denn ausgecheckt? Klingt für mich auf den ersten Blick danach, als wenn Du in der aktuellen Entwicklerversion unterwegs bist, wo nicht noch alles zusammenpasst.

/Hannes

Comments

Hallo DemoFreak,

und dank dir schonmal für die schnelle Antwort.

Ich kann bzgl. dem Checkout gerade nicht überprüfen - aber es hätte 3.9.1 sein sollen, mit Orientierung am Handbuch (Kapitel 2.4.1.):

git checkout `git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1`

Entsprechend geht es um dieses Updatefile:
https://github.com/kivitendo/kivitendo-erp/blob/release-3.9.1/sql/Pg-upgrade2/file_storage_dunning_invoice.sql

Dein Vergleich mit dem maskierten Feldnamen macht meiner Ansicht nach
nur einen simplen Textvergleich, das würde also nicht den gewünschten
Effekt haben.

Mh, davon (=einfache Textsuche) war ich auch ausgegangen. Mein Verständnis war, dass in der Spalte "files"."object_types" alle Einträge mit "dunning" --> "dunning_invoice" aktualisiert werden sollen. Die ENUM-Werte scheinen über einen Check-Constrain abgebildet zu sein (und dort sind m.E. der alte und neue Wert enthalten). Über "like" ohne "%" hatte ich mich allerdings auch gewundert, denn dann hätte ein "=" den gleichen Effekt, oder?

---

Hi,

ja, mit diesem git-checkout kommst Du auf 3.9.1

Ich hab gerade mal schnell nachgeschaut. Beim Neuanlegen der Datenbank kam zwischen 3.9.0 und 3.9.1 irgendwann die Änderung rein, dass das Feld object_type statt Typ 'text' auf den ENUM 'file_object_types' gesetzt wird.

Vergleiche hier und hier

Das einzige, was ich mir vorstellen kann, ist, dass das bisher noch keinem aufgefallen ist, weil alle ihre Datenbank updaten statt neu anlegen und dieses UPDATE eher passiert als die Anpassung des Feld-Typs. dann würde das bei einem Update durchlaufen.

Aber das ist wildes Herumraten, ich muss dann einfach mal zum Test selbst eine neue Datenbank anlegen, mal sehen, was da passiert. Hab ich noch nie gemacht, sondern immer direkt eine Kopie meine Live-Datenbank verwendet.

/Hannes

---

Aber das ist wildes Herumraten...

...und es war Käse. ;)

Ich hab unter 3.9.1 die Datenbank eines Testbenutzers gelöscht und neu angelegt, und den Benutzer problemlos anmelden können.

Muss also bei Dir an etwas anderem liegen.

/Hannes

---

Dank dir fürs (prompte!) Nachstellen.

Ich mag ja gar nicht ausschließen, dass ich etwas übersehen habe oder vom Handbuch ungewollt abgewichen bin.
Es bleibt die Frage nach dem wo.

Dann werde ich mal weiter forschen und berichten - freue mich aber über weitere Ideen.

---

Dein Text oben macht mich stutzig:

Beim Anmelden als Benutzer folgen dann noch Updates an der "Verkehrsdaten"-Datenbank.

Bei mir passiert da gar kein Update an irgendeiner Datenbank, wenn ich den eben angelegten Benutzer erstmalig anmelde. Kann es sein, dass Du da doch eine der alten Datenbanken verwendest?

/Hannes

---

Hallo Hannes,

was soll ich sagen: Ja, du hast Recht. Irgendwas ist mit der (vermeindlich (sogar mehrfach) neu angelegten) Datenbank schief. Ich habe jetzt nochmal eine neue angelegt und jetzt passt es auch.

Ich habe die Datenbanken auch nochmal miteinander (grob) verglichen:
Beide sind eher leer. Die jetzt funktionierende hat allerdings 3 zusätzliche Tabellen (part_customer_prices, purchase_basket_items, stocktakings).

Ich kann gerade weder erklärne, wie es zu der "schiefen" DB gekommen ist, noch warum das zu der eingangs beschriebenen Fehlermeldung passt (die Tabelle "files" scheint in beiden Versionen gleich zu sein. object_type ist in beiden Fällen vom Typ file_object_types).

Sei's drum - dein Vergleich und Vermutung hat mich trotzdem auf den richtigen Weg gebracht.
Also folge ich diesem jetzt Mal in Richtung Update meiner alten Datenbank.

Vielen Dank,
Gruß,
Mac