Neu Installation 3.7.0 : Fehler bei Datenbankaktualisierung

Question

Hallo,

nachdem ich nach lange zurück liegenden und gescheiterten Versuchen von Lx-Office 2.6.0 zu kivitendo umzusteigen noch eine Weile mit dem alten System gearbeitet hatte, habe ich nach dem neu Aufsetzen des Arbeitsrechners mit Ubuntu 22.04 LTS die Gelegenheit genutzt, um einen neuen Anlauf zu nehmen.

Die Installation war soweit erfolgreich. Da ich damals schon mal gescheitert bin, die alte Datenbank einzuspielen, hatte ich alles erst einmal mit einer frischen Datenbank ausprobiert.

Aktuelle Version: 3.7.0 / postgres 14
Alte Version: lx-office 2.60 / postgres 9.3

Um den Umstieg auf die Postgresql 14 zu erleichtern, wurden dem superuser, als auch den Benutzern die Passworte in postgres, wie auch kivitendo vergeben.

Erst nach der Installation und dem Anlegen von Benutzer und Mandant und einem erst Probieren, habe ich die Datenbank aus einer Sicherung ( alle-datenbanken.dump) eingespielt.

Nach dem Benutzer Login sollte die Datenbank aktualisiert werden. Also erst die Datenbank mit user und PAsswort eingetragen, nach "weiter" den superuser mit passwort eingetragen.

Dann kam diese rot unterlegte Fehlermeldung:

The database update/creation did not succeed. The file sql/Pg-upgrade2/warehouse3.sql containing the following query failed:
UPDATE parts SET onhand = COALESCE((SELECT SUM(qty) FROM inventory WHERE inventory.parts_id = parts.id), 0)
The error message was: ERROR: record "new" has no field "bin_id"
CONTEXT: SQL expression "NEW.bin_id IS NULL AND NEW.warehouse_id IS NULL"
PL/pgSQL function check_bin_belongs_to_wh() line 2 at IF
All changes in that file have been reverted.:

Und ab da ging es nicht weiter. Ich habe noch einiges anderes probiert. Auch erst die Datenbank anzulegen und danach die Daten einzufügen, aber das ist bereits im Ansatz gescheitert.

Auch habe ich versucht per

pg_dump -U -h > exported_data.sql

die Daten zu sichern und in eine bestehende Datenbank einzuspielen. Zumindest wurden die Tabellen angelegt, nur Kivitendo gibt die Daten nicht aus. Es ist, als ob keinerlei Daten existieren.

Vermutlich weil in lx-office es ja nur den Benutzer gibt und in Kivitendo der Mandant noch "zwischen geschaltet" ist und hier irgendwo der Link fehlt.

Wie auch immer: Kennt jemand eine Möglichkeit die Daten irgendwie in Kivitendo einzupflegen. Gibt es eine Möglichkeit, den Fehler "händisch" zu beheben?

Die Fehlermeldung verstehe ich auch nicht wirklich.

Answer 1

Hallo
das sieht eher nach einem schwerwiegenden Problem mit der Datenbank aus.

• Ist das Datenbankbackup komplett sind dort die Daten drinne. .sql ist
  eine Textdatei und kann mit einem Editor geöffnet werden. Letzte Zeile sollte sowas wie --Database backup completed haben
• Sind Daten zu sehen wenn Du dich über die SQL Konsole einloggst?

Ansonsten sollte es gehen ein Update von 2.6 auf 3.8 habe ich letztes Jahr erst gemacht.

Beste Grüße
Werner kivitendodienstleister

Unterstütze kivitendo mit einer Basis-Subcription

Comments

Danke schon mal für die Antwort.

Die letzten Zeilen der export_data.sql sind :

REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;--

-- PostgreSQL database dump complete

Zumindest sind Tabellen und Sequenzen zu sehen, wenn ich mi \dt ; \dT in der Datenbank abfrage.

Im pgAdmin kann ich in den Statisken sehen, dass die aus dem "alle-datenbanken.dump" eingespielte 39,86 MB groß ist und die mit dem Inhalt der .sql Datei "gefüllte" 21,63 MB groß ist.

Also müssen zumindest erkleckliche Daten vorhanden sein.

Nebenbei habe ich ein reines Ein-Mann-Geschäft. Die Datenmenge beträgt also nur ein Bruchteil anderer Betriebe.

Auf einem anderen System läuft die alte 2.6.0 Version immer noch. Solange das Neue nicht läuft, bleibt es dabei. Probleme mit de rDatenbank habe ich dort allerdings nicht.

Neuer Tag und neuer Versuch:

Was ich noch nicht gemacht hatte ist, einen einzelnen -dump der Datenbank zu machen und den einzuspielen. Das habe ich mit hilfe eines anderen Befehls und der .sql datei gemacht.

Jetzt also mit einem.dump das Gleiche:

Die Datenbank gelöscht und in kivitendo neu erstellt, also so, dass auch lgeich Tabellen angelegt werden und den .dump eingespielt: Es pasiert das Gleiche, wie vorher mit der sql. Datei:

Die Daten kommen zwar an - ob alle, kann ich nicht sehen - werden aber in kivitendo nicht angezeigt. Lediglich meine Kundengruppen waren zu sehen, der Rest nicht.

Die Datenbank gelöscht und versucht im Ganzen einzuspielen, was mangels der Datenbank und dem nicht zugewiesenen Benutzer scheiterte.

Also Datenbank in postgres angelegt und wieder eingespielt.

Beim Aufrufen des Mandanten will kivitendo dann wieder die Datenbank aktualisieren - was es in den Fällen, in denen ich die Datenbank in Kivitendo erstellt habe, nicht gemacht wurde. Die Option gab es auch nicht.

Und dann kam wieder die gleiche Fehlermeldung wie oben.

Während des restores kam allerdings auch eine ganze Reihe Meldungen:

pg_restore: warning: restoring tables WITH OIDS is not supported anymore

Diese kam über 50 mal. Und zuletzt:

g_restore: while PROCESSING TOC: pg_restore: from TOC entry 8; 2615
2200 SCHEMA public postgres pg_restore: error: could not execute
query: ERROR: schema "public" already exists Command was: CREATE
SCHEMA public;

pg_restore: warning: errors ignored on restore: 1

Diese OID scheinen ein Problem darzustellen. Dazu muss gesagt werden, dass meine Datenbank schon seit 2010 existiert.

Aber andere Frage: Wenn Du schon von 2.6.0 auf 3.8.0 gemacht hast, wie bist du da vorgegangen beim Einspielten der alten Datenbank? Gab es ein ähnliches Problem?

Answer 2

Hallo,

stimmen die Nutzer(Eigentümer | Kodierung | Zeichentyp) von alter und die Einstellungen der neuen kivitendo Installation überein?

Liste der Datenbanken mal überprüfen.

sudo -u postgres psql -l 

War zumindest bei mir das Hauptproblem bei einer Datenübernahme.

VG
Gerd

Comments

Hallo und Danke für die Antwort,

Diese Dinge passen aber. Das ist also nicht das Problem.

Gerade die "Kleinigkeiten" werden schon mal vergessen, das kenne ich auch.

Answer 3

Hallo,

Erst nach der Installation und dem Anlegen von Benutzer und Mandant und einem erst Probieren, habe ich die
Datenbank aus einer Sicherung ( alle-datenbanken.dump) eingespielt.

Hast du die Sicherung einfach in die bestehende 3.7.0 drüber gebügelt ?

• probier mal nur die Mandanten Tabelle zu sichern ( nicht die kivitendo_auth )

• in 3.7.0 nach deinem ersten Probieren die kivitendo_auth belassen

1. die Mandanten Datenbank löschen (falls angelegt)
2. die Mandanten Datenbank neu anlegen
3. die Daten aus der Sicherung in die Mandantentabelle zurück lesen
4. in kivitendo einloggen und die Datenbank mit einem Nutzer verbinden
5. als Nutzer einloggen

VG
Gerd

Comments

Hallo,

die Owner:... der eingelesenen *.sql sollten schon mit dem Eigentümer der Datenbanktabelle im neuen Kivitendo übereinstimmen. Zugriffsrechte müssen stimmen sonst kein korrekter Zugriff auf die Datenbank.

Ich würde ja einfach mal in der *.sql alle Ownereinträge "lxoffice" durch kivitendo ersetzen.

VG Gerd

---

Also das wird es nicht sein, da ich neben dem superuser ohnehin noch die User kivitendo, wie auch lxoffice angelegt hatte und die entsprechende Datenbank auch lxoffice zugeordnet hatte.

---

Und es geht sehr holperig weiter:

Zunächst habe ich in der sql.-sicherung den obigen Teil, der offensichtlich Probleme macht, auskommentiert. Danach wieder in eine leere Datenbank eingespielt und die Datenbankaktualisierung gemacht.

Dieser Fehler trat dann nicht mehr auf, aber ein paar ungewöhnliche Dinge:

Einmal wurde aufgefordert, dass doppelt vergebene Artikelnummern geändert werden. Kein Problem soweit, aber das System mag es offenbar nicht, wenn nicht alle monierten Artikel in einem geändert werden. In dem Fall geht es zurück und aller Artikel dürfen noch einmal geändert werden. Nach ein paar Anläufen ist auch dies Hürde genommen.

Der nächste Schritt war eine Zuweisung von Artikel zu einer Kategorie und einem Lagerplatz. Auch das ging nach zwei Anläufen.

Dafür gibt es jetzt wieder eine ziemlich dicke Fehlermeldung:
Nachdem:

Führe konjunkturpaket_2020.sql aus: Anpassung der Steuersätze für 16%/5% für Deutsche DATEV-Kontenrahmen SKR03 und SKR04

Erscheint dieses:

The database update/creation did not succeed. The file sql/Pg-upgrade2/konjunkturpaket_2020.sql containing the following query failed:

Und listet das gesamte script auf.

Am Ende steht dann dieser Fehlerbericht:

The error message was: ERROR: duplicate key value violates unique constraint "taxkeys_chartid_startdate"
DETAIL: Key (chart_id, startdate)=(6, 01.07.2020) already exists.
CONTEXT: SQL statement "insert into taxkeys (chart_id, tax_id, taxkey_id, pos_ustva, startdate )

             values (_chart_id,
                     (select id from tax where taxkey = current_taxkey.taxkey and rate = _new_rate::numeric),
                     current_taxkey.taxkey, -- 2, 3, 8, 9
                     current_taxkey.pos_ustva, '2020-07-01')"

PL/pgSQL function inline_code_block line 180 at SQL statement
All changes in that file have been reverted.:

Ich habe es mir noch nicht richtig angesehen und weiß noch nicht, wo der Haken ist. Aber ich kann mir vorstellen, dass das schon anderen vorgekommen ist.

---

Hallo zusammen,

ein kivitendo-Dienstleister könnte Euch helfen, ansonsten habe ich vor vier Jahren diesen Hinweis in die UPGRADE-Datei hinzugefügt:

https://github.com/kivitendo/kivitendo-erp/commit/ecefbf9abb0a7638241e51b1902b2f830850ce56

Des Weiteren:

Das Deaktivieren der Constraints zur Überwachung von verwaisten Lagerplätzen würde ich auch nicht empfehlen, bei den meisten DB-Änderungen haben sich die Entwickler etwas dabei gedacht. Ich würde eher prüfen, warum die Constraints fehlschlägt und dann gezielt die verwaisten Lagerplätze entfernen.

---

Es hat gedauert, aber die Datenbankaktualisierung ist endlich durch!

Bis dahin war es aber noch einmal sehr holprig und ich kann mir vorstellen, dass die Arbeit noch längst nicht getan ist. Aber ich kann das System benutzen und es scheinen auch alle Daten da zu sein.

Was kam nach meinem letzten Post?

In der Tat hatte ich 2020 in lx-office natürlich die Steuer geändert, was sich nun mit dem release natürlich beißt.

Ich habe den Tip von @jbueren befolgt und habe die sql scripts der sql/Pg-upgrade2/konjunkturpaket_2020* sozusagen auf "ignore" gesetzt.

ed -i 's/ignore: 0/ignore: 1/g' sql/Pg-upgrade2/konjunkturpaket_2020*

Natürlich mit meinen vollständigen Pfaden und mit "sudo" vorangesetzt, also mit root-Rechten.

Es sind insgesamt fünf, nicht drei, da für jeden Kontenrahmen je noch einmal ein Korrektur-script hinzu kam.

Das hatte alerdings wieder Fehlermeldungen zur Folge: Zuerst wurden fehlende Abhängigkeiten von je dem release_3_5_6.sql und release_3_5_6_1.sql bemängelt.

Zuerst hatte ich auch diese mit -- ignore: 1 versehen. Dann aber traten wieder andere Abhängikeitsfehler auf den Plan und zwar jedes Mal aufs neue. Es werden so einige sein.

Also habe ich -- ignore: 1 wieder gelöscht und statt dessen, die Abhängigkeit zu den konjunkturpaket_2020. - scripten auskommentiert. In beiden releases. Damit dürfen m.E. alle anderen scripte gerne eine "Verbindung" zu den release-scripten haben, nur ab da, geht es nicht weiter.

Das ging gut, bis zuletzt doch noch eine andere Abhängikeit moniert wurde. Diesmal das script sql/release_3_5_7.sql

-- @tag: release_3_5_7
-- @description: Leeres Script, das alle Upgradescripte bis zum Release 3.5.7 voraussetzt, um ein fest definiertes Schema zu definieren.
'-- @depends: release_3_5_6_1 record_links_dunning_post_delete_trigger customer_vendor_routing_id dunning_original_invoice_printed tax_point2 custom_variables_add_edit_position defaults_req_delivery_date add_transfer_doc_interval defaults_delivery_orders_check_stocked cvars_remove_duplicate_entries time_recordings_articles record_template_payment_id defaults_customer_vendor_ustid_taxnummer_unique shop_4 defaults_posting_records_default_false add_gl_imported file_storage_project customer_vendor_add_postal_invoice file_storage_dunning_documents time_recordings_remove_type orderitems_optional time_recordings_add_order defaults_transfer_settings'

Auch hier habe ich die Abhängikeit auskommentiert.

Der Übersicht halber mache ich so etwas am liebsten direkt in den scripten mit einem Editor und mit Root-Rechten ( sudo nautilus).

Nun lief die Aktualisierung zu Ende.

Bevor ich diesen Faden als gelöst markiere will ich noch einiges ausprobieren.

Es kann natürlich sein, dass bei dem einen oder anderen der Helfer hier die Alarmglocken schrillen!!! Weil ich zwar meiner Meinung nach relativ logisch vorgegangen bin, was nun alles andere als richtig sein muß.

Wenn dem so ist, lasst es mich gerne wissen.

Ach ja: Vielen Dank schon mal für jeden Beitrag hier. Weiter geholfen hat wirklich alles.

Answer 4

Diese Frage habe ich neu gestellt:

https://forum.kivitendo.de/6200/rechnungen-in-kivitendo-können-nicht-gebucht-werden

Und sie ist auch bereits gelöst.