Datenbank Hilfe

Question

Hallo, heute versuchte ich von meiner 3.8.0 Version die manuelle Installation vom 3.9.2 stable, die kividento.conf angepasst sowie die chown Sachen in der Konsole vorab erledigt. Soweit so gut auch der erste Login als Administrator verlief gut. Aber der erste Login als User eben nicht, erbitte Hilfe. Anbei der besagte abschnitt.

Datenbankaktualisierung (meine_db)

Führe parts_price_history_add_price_factor.sql aus: Preisfaktor für Entwicklung der Stammdatenpreise

Führe shop_order_items_discount.sql aus: shop_order_items haben einen identifier und referenzieren prozentualen rabatt

Führe part_customer_prices_add_description.sql aus: Kundenspezifischen Preisen Beschreibung und Bemerkungen/Langtext hinzufügen

Führe file_storage_sales_order_intake.sql aus: Dateispeicher auch für Auftragseingänge

Führe file_storage_purchase_quotation_intake.sql aus: Dateispeicher auch für Angebotseingänge

Führe file_storage_purchase_order_confirmation.sql aus: Dateispeicher auch für Lieferantenauftragsbestätigungen

Führe file_object_type_as_enum.sql aus: Objekttype von Dateien in Enum ändern

Führe deliveryorder_type_to_record_type.sql aus: Convert deliveryorder_type to record_type enum

Führe change_file_backend_to_enum.sql aus: Backend für Dateien auf Type Enum setzen

Führe oe_sales_order_intake_type.sql aus: Neuer Auftragsbeleg: Auftrags-Eingang (sales_order_intake)

Führe update_employee_base_data.sql aus: Hintergrundjob für regelmäßiges Aktualisieren der Employee-Basisdaten aus der Auth-Tabelle


  Fehler!

The database update/creation did not succeed. The file sql/Pg-upgrade2/update_employee_base_data.sql containing the following query failed:
INSERT INTO background_jobs (type, package_name, active, cron_spec, next_run_at) VALUES ('interval', 'UpdateEmployeeBaseData', true, '*/5 * * * *', current_timestamp)
The error message was: ERROR:  duplicate key value violates unique constraint "background_jobs_pkey"
DETAIL:  Key (id)=(42) already exists.
All changes in that file have been reverted.: 

Answer 1

Hallo Turtle,

schau mal in das

Menu ---> System ---> Hintergrund-Jobs und Task-Server ---> Task-Server-Steuerung

" Jobliste " ---> zeigt alle Hintergrund-Jobs an

• gibt es da einen Eintrag "UpdateEmployeeBaseData" ( steht vermutlich auf der 2 Seite ) ?

Ist diese Eintrag schon vorhanden schlägt das Update Script "sql/Pg-upgrade2/update_employee_base_data.sql" fehl.

INSERT INTO background_jobs (type, package_name, active, cron_spec, next_run_at) VALUES ('interval', 'UpdateEmployeeBaseData', true, '/5 *', current_timestamp)

ERROR: duplicate key value violates unique constraint

---> Doppelte Schlüsselwerte verletzen die Eindeutigkeitsbedingung

DETAIL: Key (id)=(42) already exists.

Eventuell Eintrag löschen oder das Skript auskommentieren.

VG Gerd

Comments

Guten Morgen Gerd,
komme momentan nicht an die Menüleiste von kivitendo, habe jetzt mal in der kivitendo.conf den Eintrag unter [task server] 'send_email_to' auskommentiert und im Administrator Login den Eintrag Task-Server für diesen Mandanten mit der folgenden BenutzerIn ausführen auf Taskserver nicht ausführen gestellt.

Jedoch weiterhin

Fehler!

The database update/creation did not succeed. The file sql/Pg-upgrade2/oe_purchase_order_confirmation_order_types.sql containing the      llowing query failed:
ALTER TYPE order_types ADD VALUE IF NOT EXISTS 'purchase_order_confirmation'
The error message was: ERROR:  ALTER TYPE ... ADD cannot run inside a transaction block
All changes in that file have been reverted.: 

---

Natürlich dürfen alle User mir helfen, nicht nur Gerd. Noch etwas ist mir aufgefallen,

wenn ich auf Detail klicke passiert erst mal gar nichts, nur wenn ich es im neuem Fenster öffne erhalte ich folgendes:

Fehler!

get_objects() - DBD::Pg::st execute failed: ERROR:  column t1.allowed_documents_with_no_positions does not exist
LINE 15:   t1.allowed_documents_with_no_positions,
       ^ at /usr/share/perl5/Rose/DB/Object/Manager.pm line 2016.
at /home/kivi/www/kivitendo/kivitendo-erp/bin/mozilla/login.pl line 54.

klicke ich auf weiter kommt

Fehler!

The database update/creation did not succeed. The file sql/Pg-upgrade2/oe_purchase_order_confirmation_order_types.sql containing the following query failed:
ALTER TYPE order_types ADD VALUE IF NOT EXISTS 'purchase_order_confirmation'
The error message was: ERROR:  ALTER TYPE ... ADD cannot run inside a transaction block
All changes in that file have been reverted.: 

---

oje Leute, ein zurück ist auch nicht mehr, sehe gerade das wohl das Datenbankbackup nicht richtig erstellt worden ist, oje oje

---

Hallo Turtle,

ja, kaputtes Backup ist nicht gut.

Mal die Frage ? Hast du nach der Umstellung auf 3.9.2
auch noch mal getestet ob auch alle neuen Module/Bibliotheken installiert sind.

# im Verzeichnis kivitendo-erp/
$ ./scripts/installation_check.pl

VG Gerd

---

danke für den Hinweis aber ja habe ich

---

so hier Lieben, bin jetzt fast durch mit den manuellen DB Sachen. Google KI meinte bei sehr vielen davon:

Dieser Fehler hat zwei Ursachen:

Transaktionsproblem: .... kann nicht innerhalb eines Transaktionsblocks ausgeführt werden.
Das Script kann ... nicht direkt ändern, um die Transaktion zu steuern.

Also gehe ich davon aus das die update scripte nicht so toll sind, ich musste bei einigen sogar Zeilen auskommentieren, das war sehr viel Arbeit und ich musste jedes mal die Sperre (Admin) für Kivitendo aufheben. Und den Befehl in der Konsole, die mit der DB verbunden war, manuell ausführen.

Wobei ich beim letzten Script (../sql/Pg-upgrade2/shop_images_dont_skip_positon.sql) das viele Zeilen inne hat, nicht sicher bin, ob das alles so fein funktionierte. Vielleicht erhalte ich dazu separate Hilfe (Support) wie ich das nochmals in der Konsole ausführe damit das seine Ordnung hat.

Aber ich habe weiterhin einen Fehler den ich noch nicht erledigen kann / habe, dafür komme ich nun direkt in kividento, leider ist ein Arbeiten damit noch weit entfernt. Anbei Bild, in Hoffnung um Hilfe.

---

Hallo Turtle,

hab hier mal ein Update von 3.8 auf 3.9.2 auf einem älteren System durchlaufen lassen.

System Debian 11 - bullseye
psql --version
psql (PostgreSQL) 13.22 (Debian 13.22-0+deb11u1)
perl --version
perl 5, version 32, subversion 1 (v5.32.1)

Folgende Pakete mußten nachinstalliert werden

libencode-imaputf7-perl
libmail-imapclient-perl
libuuid-tiny-perl

• login als Administrator
  ---> Datenbankupdate

• login als Benutzer
  ---> Anzeige Datenbankaktualisierung
  Details anzeigen --->

• Liste der noch einzuspielenden Datenbankupgrades:
  auch ok ( ist ziemlich viel, sind wohl etwas mehr als 60 )

Das läuft hier auch alles sauber durch.
Erstmal keine Probleme erkennbar.

• weiter --->
  Anmedung im Mandanten fertig und ok

Eventuell blockieren fehlerhafte Einträge in der Datenbank das Update ?

Welches System läuft bei dir ?
Hoffentlich findet sich doch noch ein Datenbanksicherung für einen neuen Versuch ?
Wenn Datenbank kaputt wird es schwierig.

VG Gerd

---

Hallo Gerd, habe ein ubuntu 24.04.3 LTS am Start. Die drei Pakete (libencode-imaputf7-perl, libmail-imapclient-perl, libuuid-tiny-perl) sind bei mir bereits installiert. Ich kann mittlerweile auch etwas damit arbeiten, zumindest sind meine letzten Daten die ich anlegte Auftrag / Rechnung und so auch da. Aber es Blobt hier und da das rot hinterlegte Fenster (siehe Bild oben) immer mal wieder auf.

Wäre natürlich schön wenn es sauber laufen würde, habe auch schon versucht './scripts/dbupgrade2_tool.pl' in der Konsole zu starten, läuft auch ohne etwas durch, nur das rote Fenster ist da hartnäckiger. Was mich noch interessieren würde wäre die Tabelle 'sales_orders' und die Spalten und Werte dazu. Jene habe ich selbst angelegt, da habe ich so meine zweifel. Oder gibt es eine generelles DB Update das ich in der Konsole anstupsen kann?

---

Hallo Turtle,

zur Tabelle 'sales_orders' kann ich nichts sagen, gibs ja bei mir nicht.

Was es in der db gibt ist die Tabelle

order_statuses

                                            Tabelle »public.order_statuses«
   Spalte    |             Typ             | Sortierfolge | NULL erlaubt? |                Vorgabewert                 
-------------+-----------------------------+--------------+---------------+--------------------------------------------
 id          | integer                     |              | not null      | nextval('order_statuses_id_seq'::regclass)
 name        | text                        |              | not null      | 
 description | text                        |              |               | 
 position    | integer                     |              | not null      | 
 obsolete    | boolean                     |              | not null      | false
 itime       | timestamp without time zone |              |               | now()
 mtime       | timestamp without time zone |              |               | 

Indexe:

"order_statuses_pkey" PRIMARY KEY, btree (id)
"order_statuses_name_key" UNIQUE CONSTRAINT, btree (name)

Fremdschlüsselverweise von:

TABLE "oe" CONSTRAINT "oe_order_status_id_fkey" FOREIGN KEY (order_status_id) REFERENCES order_statuses(id)

Trigger:

mtime_order_statuses BEFORE UPDATE ON order_statuses FOR EACH ROW EXECUTE FUNCTION set_mtime()

VG Gerd

---

vielen lieben Dank, die Tabelle 'order_statuses' habe ich genau so auch. Ich nutze gerne phppgadmin dafür.
Die Tabelle 'sales_orders' habe ich soeben gelöscht, das wurde mir von der google KI vorgeschlagen.

Weist du ob es so etwas gibt, quasi für DB so wie './scripts/installation_check.pl -ro' für die capan/perl Sachen bzw. ein Script das die DB prüft und evtl. entsprechend ergänzt? Wäre toll.

---

Hallo Turtle,

offenbar hat deine db Eigenheiten.

Ein Testscript kenne ich so nicht.
Es gibt Tests um neue Programmteile mit einer Testdatenbank zu testen.
- siehe in der config/kivitendo.conf unter [testing] [testing/database]
- im Ordner 't'

• Sonst eine neue Datenbank anlegen.
• Unterschiede zur aktuellen Datenbank suchen
• eventuell Daten in die neue Datenbank migrieren.

Sieht nach ein wenig Arbeit aus, aber wen es hilft den Datenbestand für die nächste Zeit wieder auf ordentliche Füße zu stellen.
Dann laufen die zukünftigen Updates wahrscheinlich auch sauber durch.

VG Gerd

---

Okay, danke. Das mit der neuen parallelen DB und die alten Daten zu migrieren, wäre in der Tat sehr viel Arbeit. Vielleicht mache ich mich in der kommenden Weihnachtszeit daran.