Bug: Inkompatibilitäten mit postgres 12

Question

Wie schon G. Richardson im Bugtracker festgestellt hat, ist kivi nicht mit Postgres12 kompatibel.

Das betrifft die folgenden Tabellen:

• public.assembly
• public.parts
• public.crm
• public.delivery_order_items
• public.ekartikel
• public.ekbon
• public.ekdefaults
• public.ekkunde
• public.ektext
• public.invoice
• public.partsgroup
• public.orderitems

Bei Archlinux ist postgres 12 seit 2019-11-18 in den Repos.

-----------------------------------------------------------------
  pg_upgrade run on Sat Jan 18 11:35:01 2020
-----------------------------------------------------------------

Führe Konsistenzprüfungen durch
-------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               fatal
Ihre Installation enthält Tabellen, die mit WITH OIDS deklariert sind, was
nicht mehr unterstützt wird. Entfernen Sie die oid-Spalte mit
    ALTER TABLE ... SET WITHOUT OIDS;
Eine Liste der Tabellen mit dem Problem ist in der Datei:
    tables_with_oids.txt

Da es ja kein offenes Bug-Tracking-System gibt bestätige ich hier, dass das ein Bug ist.

Hinweis an Robert Farr: Die Tabellen von erp-kasse sind ebenfalls betroffen.

Probeweise habe ich "ALTER TABLE ... SET WITHOUT OIDS;" auf den Tabellen ausgeführt.
Dann kann ich mit erpkasse nicht mehr kassieren.

Viele Grüße und eine schöne Woche

Iris

Answer 1

Hallo, warum hat Kivitendo kein Bug-Tracking-System?

MfG

tstrebel

Comments

Warum? Keine Ahnung.

Dass nicht kannst du hier nachlesen:

Analog dazu wird es auch kein offenes Bug-Tracking-System geben,
sondern Einträge hierfür werden über Foreneinträge generiert oder
direkt von Partner (s.a. Partnerprogramm hier) erstellt.

---

Hi,
die Pflege eines Bug-Tracking-Systems in denen die gesamte Welt Meldungen machen kann ist leider viel zu aufwändig für unsere Projekt-Ressourcen.

Deswegen haben wir vor einigen Jahren entschieden, dass nur noch Bugs von Personen gemeldet werden können, die diese von Ihrer Kompetenz auch lösen können.

Damit sind die "false Positives" verschwunden und auch der kommunikative Overhead wurde minimiert.

Das was dann noch im Forum an Fragen aufkommen ist dagegen wieder gut "ehrenamtlich" machbar.

Deswegen hier die Rückmeldung:

Im aktuellen kivitendo funktioniert jetzt die Unterstützung für Postgresql 12 und ich hab den Bug gerade geschlossen:

https://www.kivitendo.de/redmine/issues/415

Bitte einmal Gegenprüfen.

Danke

---

Danke für die Rückmeldung.

Testen kann ich leider augenblicklich nicht, da auch die Tabellen von erp-Kasse betroffen sind.

Da muss ich erst warten bis dafür auch ein Update zur Verfügung steht.

Viele Grüße und eine schöne Woche

Iris

---

Hi,
tja, die Anforderung müsste dann eher im OpenKonto-Forum, o.ä. angemeldet werden.
Da können wir von kivitendo wenig helfen, ggf. noch dein kivi-Dienstleister.

Gruß

---

Openkonto-Forum?

Gibt es keins

und außerdem wurde ich da durchgereicht. Da wollte ich eigtl. nicht hin. Alternativ müsste ich kivitendo komplett verlassen. Weil ein anderes POS als erp-kasse für kivitendo gibt es wohl keins.

einen "Dienstleister" habe ich keinen.

Selbst ist die Frau

Für mich bedeutet Open Source, dass ich als User aktiv mithelfe und sowas wie oben eben melde. Und da erp-kasse eben nicht Open Source ist, kann ich auch nichts machen als warten.

---

Ist etwas off-topic, aber ich kann mich schwerlich zurückhalten:

Dann bleiben ja noch drei Optionen

• Selbst ist die Frau: Eine neue OpenSource Kasse programmieren
• kivitendo verlassen
• In den Kaufladen von erp-kasse gehen und eine neue Version mit entsprechenden Funktionen gegen langweiliges Geld tauschen

Je nach Kaufvertrag kann man beim letzten Punkt den Hersteller noch verklagen oder anderweitig überreden etwas zu liefern...

Wie dem auch sei, viel Erfolg!

---

Salut

ich hatte vor nicht allzu langer Zeit mir einen Spiegel-System einer produktiven Umgebung gebaut, um Tests und andere
Versuche zur besseren Verständnis mir zu bauen. Das produktive System ist eine Fedora31 Umgebung mit einer Postgres11 Datenbank, das Zielsystem ist eine Postgres12 Datenbank.

Bei jeden Import einer PG11 Datenbank in meine PG12 Umgebung gab es nervige Meldungen, die ein Fehlen
des OIDS mokierten. Nachfolgendes SQL behob das Problem

ALTER TABLE public.assembly SET WITHOUT OIDS;
ALTER TABLE public.parts SET WITHOUT OIDS;
ALTER TABLE public.crm SET WITHOUT OIDS;
ALTER TABLE public.delivery_order_items SET WITHOUT OIDS;
ALTER TABLE public.ekartikel SET WITHOUT OIDS;
ALTER TABLE public.ekbon SET WITHOUT OIDS;
ALTER TABLE public.ekdefaults SET WITHOUT OIDS;
ALTER TABLE public.ekkunde SET WITHOUT OIDS;
ALTER TABLE public.ektext SET WITHOUT OIDS;
ALTER TABLE public.invoice SET WITHOUT OIDS;
ALTER TABLE public.partsgroup SET WITHOUT OIDS;
ALTER TABLE public.orderitems SET WITHOUT OIDS;

Danach von def PG11 Quellumgeung ein Export mit anschließenden Import klappte nach der Ausführung des obigen SQL Scripts.

---

Hallo zusammen,

ich will kurz meine Erfahrung berichten:

Nachdem ich meine PG-11 Instanz - ein reines Kivitendo-ERP ohne Extras - auf 3.6.5.1 hochgezogen habe, schlug der Import der Datenbanken auf PG-12 fehl, da es noch Tabellen mit OIDs gab (obwohl im Changelog steht, die PG-12 Kompatibilität sei hergestellt worden).

Notwendig war - wie schon von Groovyman beschrieben - vielen Dank dafür - ein "alter table" auf einige Tabellen.
Bei mir waren das:

ALTER TABLE public.assembly SET WITHOUT OIDS;
ALTER TABLE public.parts SET WITHOUT OIDS;
ALTER TABLE public.delivery_order_items SET WITHOUT OIDS;
ALTER TABLE public.invoice SET WITHOUT OIDS;
ALTER TABLE public.partsgroup SET WITHOUT OIDS;
ALTER TABLE public.orderitems SET WITHOUT OIDS;

Danach ein weiterer Export und Import im neuen System und es läuft.

Gruß
VK

---

Hallo,

habe kivitendo 3.5.6.1 i.v.m postgresql 10
Wollte auf die aktuelle postgresql 14 aktualisieren, bleibe aber am 'WITH OIDS' hängen.

Führe Konsistenzprüfungen durch
-------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for tables WITH OIDS                               fatal

Ihre Installation enthält Tabellen, die mit WITH OIDS deklariert sind,
was nicht mehr unterstützt wird. Entfernen Sie die oid-Spalte mit
    ALTER TABLE ... SET WITHOUT OIDS;
Eine Liste der Tabellen mit dem Problem ist in der Datei:
    tables_with_oids.txt

Und bei mir sind das nicht nur ein paar Tabellen, sondern eine ganze Menge.

In database: kerp_sit
public.custom_data_export_queries
public.custom_variable_config_partsgroups
public.customer
public.custom_variables_validity
public.custom_variable_configs
public.custom_data_export_query_parameters
public.custom_variables
public.datev
public.delivery_order_items_stock
public.delivery_orders
public.department
public.buchungsgruppen
public.bin
public.bank_transactions
public.business
public.csv_import_profiles
public.contacts
public.chart
public.bank_accounts
public.assortment_items
public.background_job_histories
public.assembly
public.acc_trans
public.background_jobs
public.bank_transaction_acc_trans
public.dunning_config
public.employee_project_invoices
public.employee
public.exchangerate
public.follow_ups
public.generic_translations
public.files
public.finanzamt
public.follow_up_access
public.follow_up_links
public.email_journal
public.email_journal_attachments
public.oe
public.letter_draft
public.invoice
public.leads
public.history_erp
public.makemodel
public.orderitems
public.part_classifications
public.letter
public.notes
public.language
public.partsgroup
public.project_participants
public.printers
public.price_rules
public.project_phase_participants
public.pricegroup
public.price_factors
public.project
public.payment_terms
public.parts_price_history
public.prices
public.price_rule_items
public.periodic_invoices_configs
public.periodic_invoices
public.reconciliation_links
public.project_statuses
public.record_links
public.record_templates
public.project_phases
public.requirement_spec_acceptance_statuses
public.requirement_spec_complexities
public.requirement_spec_orders
public.requirement_spec_items
public.project_roles
public.requirement_spec_item_dependencies
public.requirement_spec_statuses
public.requirement_spec_types
public.requirement_spec_predefined_texts
public.sepa_export
public.requirement_specs
public.requirement_spec_pictures
public.schema_info
public.sepa_export_items
public.requirement_spec_risks
public.requirement_spec_versions
public.requirement_spec_text_blocks
public.status
public.shipto
public.stocktakings
public.shop_images
public.shops
public.todo_user_config
public.taxkeys
public.tax_zones
public.sepa_export_message_ids
public.shop_parts
public.taxzone_charts
public.user_preferences
tax.report_categories
public.trigger_information
public.transfer_type
public.units_language
tax.report_variables
public.warehouse
public.translation
public.drafts
public.csv_import_profile_settings
public.ar
public.units
public.vendor
public.tax
public.delivery_order_items
public.ap
public.shop_order_items
public.shop_orders
public.dunning
public.inventory
public.parts
public.part_customer_prices
tax.report_headings
public.contact_departments
public.record_template_items
public.contact_titles
public.requirement_spec_parts
public.gl
public.defaults
public.greetings

In database: kivitendo_auth
auth.user_group
auth.user
auth.user_config
auth.session
auth.group
auth.master_rights
auth.session_content
auth.schema_info
auth.group_rights

Können diese Spalten jetzt entfernt werden oder besser nicht ?
Welche postgresql Versionen sind denn nun eigentlich unterstützt

---

Nachdem dieser Beitrag wieder zum Leben erwacht ist: @jbueren

kivitendo verlassen

Schon vor einem Jahr

In den Kaufladen von erp-kasse gehen und eine neue Version mit entsprechenden Funktionen gegen langweiliges Geld tauschen

Hatte ich versucht. Ohne Erfolg. Weil ich bin ja ein langweiliger User bin, der nicht jeden Monat Geld überweist und auch noch doofe Fragen stellt.

Je nach Kaufvertrag kann man beim letzten Punkt den Hersteller noch verklagen oder anderweitig überreden etwas zu liefern...

Überreden hatte ich auch versucht mit dem Angebot mitzuhelfen und mit dem Angebot mir den Code anzuschauen, damit die Änderungen eingepflegt werden können. Hätte ich auch ohne Geld gemacht. Nur aus OpenSource heraus. Bzw. aus Eigennutz.

Auch das wurde abgelehnt. Mit der Begründung man müsse erst "qualifizierte Programmierer" finden, die sich der Sache annehmen, damit man dann wieder Geld verlangen kann.

Die Suche nach Programmierern war dann erfolglos. Und jetzt gibt es niemanden mehr, der erp-Kasse nutzt. Tut mir nur leid für Herrn Lindemann, dass es genau ein Jahr gedauert hat sein Werk zu zerstören.

Und jetzt ist erp-Kasse TOT. Das heißt es gibt kein POS für kivitendo mehr aus Ignoranz.

R.I.P.

---

Mach auf jedenfall vorher eine Datensicherung ansonsten können die OIDS entfernt werden.
Ich hatte damals glaub die Postgres12 aufgesetzt und eine Datensuícherung eingespielt. Bin mir aber nicht mehr so sicher.
Und alles ohne Gewähr.
Beste Grüße
Werner kivitendodienstleister

---

Hallo Werner,

Danke für die schnelle Rückmeldung.
Backup mache ich ohnehin immer. Wollte nur sicher gehen, daß das entfernen der OIDS kein Problem darstellt.

Wäre es eventuell möglich mit der 3.6.0 hier eine Routine einzubauen, welche die vorhandene OIDS in der DB entfernt ?
Das wäre bestimmt sinnvoll, oder ?

Lieben Gruß
Christian

---

Eigentlich (auch) eine gute Idee.

Im Kundenprojekt hab ich folgendes Skript gesehen, ich frag mal beim entsprechendem Entwickler nach.

-- @description: OIDs von Tabellen entfernen
-- @depends: release_3_5_6
ALTER TABLE assembly             SET WITHOUT OIDS;
ALTER TABLE delivery_order_items SET WITHOUT OIDS;
ALTER TABLE invoice              SET WITHOUT OIDS;
ALTER TABLE orderitems           SET WITHOUT OIDS;
ALTER TABLE parts                SET WITHOUT OIDS;
ALTER TABLE partsgroup           SET WITHOUT OIDS;

---

Hallo Jan,

deine Liste ist ein wenig kurz.
Meine war da erheblich länger (siehe oben) und meine Version war 3.5.6.1

Jetzt bin ich auf 3.5.8, ohne OIDS mit postgreSQL 14.1

---

Hallo Christian,
die zusätzlichen Tabellen haben nichts mit kivitendo zu tun, sondern sind einem Fork namens Openkonto zuzuordnen.
Infos dazu gibt es ggf. hier:

http://www.openkonto.de/

Oder wie es rwollis gesagt hat: "Und jetzt ist erp-Kasse TOT. "

Der Fork ist von 2013 und wir supporten und unterstützen seit 2013 diese Entwicklung nicht.

---

Hallo Jan,

habe die 'Kasse' nie benutzt. Und ja, ich experimentiere schon lange mit kivitendo, bereits seit lx-office-erp.
Kann man das problemlos wieder entfernen ?

Danke und Gruß
Christian

---

Hi,
ja, die zusätzlichen Tabellen werden von kivitendo schlicht ignoriert. Die kannst Du sicher entfernen.

Hinweis: Das Upgrade-Skript zur Entfernung der OIDs in Bezug auf die kivitendo Tabellen ist jetzt drin und wird dann in Version 3.6.1 ausgeliefert.

Gruß

---

Hallo Jan,

Danke für die OID-Info.

bzgl. der Tabellen von erp-Kasse. Sind das alle Tabellen, welche public. als prefix haben ?

Gruß
Christian

---

Hallo Christian,

zu den Tabellen von Openkonto kann ich nichts sagen, weil ich erp-kasse mit kivitendo betrieben habe. Die Tabellen von erp-kasse sind:

CREATE TABLE ekbon (
CREATE TABLE ekartikel (
CREATE TABLE ekkunde (
CREATE TABLE ektext (
CREATE TABLE erptasten (
CREATE TABLE ekdefaults (
CREATE TABLE inventurdata(

Das habe ich aus der install.sql von erp-kasse. Ich denke du kannst die Tabellen aus deiner Installation mit denen aus dem git vergleichen: /sql/lx-office.sql.

Die Tabellen von kivitendo sind alle im schema public. Die Tabellen, die bei dir vorhanden sind und im kivitendo nicht, müssen dann aus openkonto kommen.

Deine superlange Liste von oben kannst du auf jeden Fall NICHT komplett löschen. Dann sind nämlich keine kivitendo Tabellen mehr vorhanden.

Das Upgrade-Skript von Jan aktualisert die vorhandenen kivi Tabellen. Was dann noch übrig bleibt kann ggf gelöscht werden.

Ich würde den Rest aber sicherheitshalber einzeln kontrollieren.

Viele Grüße

Iris

---

Vielen Dank,

meine obige Liste enthält KEINE Namen, welche mit ek beginnen.
Somit lasse ich das erst einmal so wie ist. Ich denke auch nicht, daß ich da etwas dann wegmachen müsste.

Ich war wohl irgendwie verwirrt, weil Jan meinte meine lange Liste rührte von erp-Kasse, was ja laut Iris offensichtlich nicht der Fall ist, da ja alle public. Tabellen zu kivi gehören.

Danke Iris

Gruß
Christian

---

de rien 😉