Das ist ja echt kurios... Die TMP-Tabellen sind Überbleibsel einer vorherigen Migration. Die enthalten die Sicherungen für die alten Tabellen. Das hatte ich nur als Panik-Rückfallösung eingebaut :-). Die anderen Tabellen (RECEIVER) wären doch recht wichtig, weil da Adreßdaten zu den Dokumenten drinstehen (sollten). Wenn Du die löschst, könnte es sein, daß manche Dokumente keine Adressen mehr haben.

Die Tabellen wurde wieder neuerstellt, beim ersten Starten.
Aber diese Update Vorgang kann ich bei meinem anderen nicht verwenden, da die Tabellen gefüllt sind. Daher würde ich dich bitten, die Überprüfung dennoch zu machen bzgl. des Scripts.

Hi Ralf,

wollte mal Fragen, ob du Zeit gefunden hast das Script mal zu prüfen bzgl. des Upgrade Problems?

@rheydenr
Hi Ralf, ich stehe weiterhin an der gleichen Stelle und kann nicht updaten. Hast du mal schauen können oder eine Idee?

Moin, tut mir leid für die Verzögerung, es ist gerade echt viel los...

Ich hab nochmal in das Skript geschaut. Die Tabelle FKT_DOCUMENTRECEIVER ist erst 2019 dazugekommen, vorher war sie definitiv nicht da. Wenn die Tabelle also in Deiner Datenbank ist, muß das durch ein Update passiert sein. Wenn Du die Tabelle löschst, sind alle Empfängeradressen aus den Dokumenten weg (nicht die Kundenstammdaten). Bringt also wahrschenlich nicht viel.

Was passiert denn, wenn Du die Tabelle nicht löschst, sondern umbenennst? Dann kannst Du die ja anschließend wieder zurück umbenennen.

@rheydenr
Hi Ralf,
konnte es noch nicht testen, aber wie soll ich dann mit den restlichen Tabellen umgehen? Die drei folgenden Tabellen haben ja Probleme gemacht, beim Update meines anderen Mandanten welche hier auch existieren.

FKT_ADDRESS_CONTACTTYPES (gefüllt)
FKT_DOCUMENTRECEIVER (gefüllt)
TMP_FKT_DOCUMENT (leer)

Ich würde es erst mal mit dem Umbenennen versuchen. Das geht am schnellsten direkt im Skript (einfach den Tabellennamen suchen und ersetzen). Die Tabelle TMP_FKT_DOCUMENT  kannst Du gefahrlos löschen, das ist nur eine Zwischentabelle.

Hallo zusammen,

ich habe auch ein update auf 2.1.2d (von 2.0.5) versucht, bekomme nun aber diesen Fehler (s. Anhang).

Mein System:
openjdk version "11.0.15" 2022-04-19
Linux Mint 20.3 64Bit
MySQL Server: 10.3.34-MariaDB-0+deb10u1 Debian 10

Jemand eine Idee ?

Grüße
Philipp

@pumoeckl 

Das sieht für mich danach aus als ob der Zugriff auf die Datentabellen nicht korrekt funktioniert.

U.U. kann es auch daran liegen, dass Du MariaDB und nicht MySQL verwendest.

Da sollte Ralf (@rheydenr) mal drüber schauen.

LG
Jürgen

Moin, ich überlege gerade, was dieser Fehler hier zu sagen hat:

"Foreign key constraint is incorrectly formed"

Das sollte eigentlich nicht passieren. Ich wüßte auch gerade nicht, was an dem Statement verkehrt sein soll. Muß ich mal checken.

EDIT: Hab's gerade mal auf meiner DB ausprobiert, das Statement ist ok. Muß also andere Ursachen haben. Allerdings läuft das noch unter MySQL 5.7. Ich hoffe nicht, daß sich die Syntax so kraß geändert hat...

@rheydenr 

Ich glaube eher, dass das Problem im mittlerweile bestehenden Unterschied MySQL <--> MariaDB liegt 🙁

LG
Jürgen

Das Problem war bei mir, dass manche tables mit unterschiedlichen Datenbank-Engines liefen. Zwischenzeitlich wurde mal der Server umgezogen, und damit auch ein Wechsel von MYSQL zu MariaDB vollzogen. Vermutlich hatte sich dadurch etwas Chaos eingeschlichen.
Man kann das aber damit lösen, dass man alle tables der SQL-Datenbank auf InnoDB stellt. Anbei ein kleines HowTo.

Danach habe ich Fakturama noch einmal frisch installiert, und nun läuft das wunderbar.

Prinzipiell wäre es schon zu begrüßen, wenn Fakturama auch in Zukunft mit den offenen Alternativen von MYSQL und JAVA laufen würde (was es ja derzeit noch tut), und sich nicht in die Abhängigkeit von großen Softwarefirmen begibt.

@pumoeckl 

Erst mal danke für die Informationen und das HowTo!
Es wird aber auch im Handbuch grundsätzlich empfohlen die Datenbank auf InnoDB zu stellen, bzw. gleich als InnoDB zu erstellen.

Was Java betrifft, kannst Du (fast) jede beliebige Version benutzen; das ist unabhängig ob die bspw. von Oracle oder Adoptium kommen.

In Bezug auf SQL, da gibt es schon länger die Überlegung auf MariaDB zu migrieren, aber das ist kein trivialer Schritt und nicht von "heute auf morgen" erledigt. Da ist einiges im Hintergrund anzupassen, und dann muss auch darauf geachtet werden, dass die Daten einwandfrei übernommen werden können.

LG
Jürgen