Problem alte 1.4 DB in 1.5 zu integrieren

Hallo zusammen,

aus diversen Gründen konnte ich keine Datensicherung mehr aus meinem alten 1.4 CAO erstellen.

Daher habe ich nun “einfach” den kompletten Mandanten Ordner kopiert und im neuen 1.5 eingelesen.

Soweit hat das auch alles funktioniert und ich kann auch keine Fehler oder fehlende Daten feststellen.

Allerdings kann ich nun keine Datensicherung mehr durchführen.
Diese hängt sich jedesmal beim file “artikel_stuecklist” auf.

Im DB Ordner fällt auf dass die Datei artikel_stuecklist.frm aus 2017 ist während alles andere aktuell ist. Neben artikel_stuecklist.frm sind auch noch plz.frm & blz.frm aus 2017.

Im CAO Admin bekomme ich bei genau diesen 3 Dateien auch einen Fehler angezeigt “upgrade required” aber die Funktion “reparieren” löst das Problem leider nicht sondern zeigt die Meldung “table is marked as crashed”.

Kann mir hier jemand weiterhelfen bitte?

Danke und liebe Grüsse,
Michael

Da könnte das Kommandozeilentool myisamchk.exe helfen.

Dazu die Kommandozeile aufrufen und in das Datenbankverzeichnis wechseln.

z.B

Code: Alles auswählen

cd \Programme\MariaDB\data\datenbankname\

Von dort aus das Tool aufrufen

Code: Alles auswählen

..\..\bin\myisamchk.exe -r artikel_stuecklist

Das hat schon mal geholfen. Danke.
Jetzt bleibt die Datensicherung bei registry_log hängen

Und das hilft nicht ?

Code: Alles auswählen

..\..\bin\myisamchk.exe -r registry_log

Leider nein….
Screenshots anbei

Bildschirmfoto 2024-01-31 um 06.58.47.png

Bildschirmfoto 2024-01-31 um 07.08.03.png

Die Fehlermeldung hat soweit ich das sehen kann nichts mit dem myisamchk Befehl zu tun.
Ebenso sagt die Meldung nichts über die Tabelle

Im CAO_Admin gibt es im Menü unter "akt. Mandant->DB-Status" die Möglichkeit die Tabellen zu prüfen.
Was wird denn dort noch anzeigt? Auch nach dem drücken auf Reparieren.
Bzw. wo bricht der Admin ab?

Das Reparieren kann man noch erweitern (nicht über CAO)
Über ein geeignetes Tool (HeidiSQL oder mysql.exe auf der Kommandozeile)

Code: Alles auswählen

REPAIR TABLE <tabellen_name> USE_FRM; 

Prüfen bzw. Reparieren im Admin ergibt folgendes:

Bildschirmfoto 2024-01-31 um 15.57.26.png

Bildschirmfoto 2024-01-31 um 15.56.27.png

Wie genau muss ich die Kommandozeile schreiben?
Tabellen Name = registry_log?
Muss ich zuvor den Mandanten auswählen über ein Kommando?

Vielen lieben Dank nochmals

Zuerst in das Datenbankverzeichnis\bin wechseln

Code: Alles auswählen

cd \programme\mariadb 10.5\bin

Dort die mysql.exe aufrufen

Code: Alles auswählen

mysql.exe -u root -p  <enter>

Dort muss jetzt das root Passwort eingegeben werden.
Dann die Datenbank auswählen und den Reparaturversuch starten

Code: Alles auswählen

USE glp; <enter>
REPAIR TABLE registry_log USE_FRM; <enter>

Sonst wird es etwas komplizierter. Man kann z.B die Tabelle registry_log löschen und neu anlegen. Da stehen jetzt keine Lebenswichtigen informationen drin. Es stimmt auch etwas mit der Tabelle "warengruppen" nicht.

Super - vielen lieben Dank!!!!
Die Datensicherung funktioniert wieder fehlerfrei!!!

Bei der Tabelle Warengruppen zeigt mir der DB-Status im admin leider immer noch eine Fehlermeldung an aber ich konnte bisher keine Fehler entdecken:

"Found a row where the auto_increment column has the value 0"

Reparieren im admin sagt anschliessend Status = OK.

Prüfen im admin zeigt aber wieder die obige Fehlermeldung an.

REPAIR TABLE warengruppen_log USE_FRM;
Hat den Fehler dort auch nicht beheben können.
Muss ich mir da Sorgen machen? Was könnte ich hier noch probieren, oder einfach ignorieren?

Anyway.... Mein eigentliches Problem ist ja erstmal gelöst.
Vielen lieben Dank nochmal.

Guten Morgen,

und was lernen wir daraus?

Muss ich mir da Sorgen machen? Was könnte ich hier noch probieren, oder einfach ignorieren?

Ich würde eine neue Warengruppe über die allgemeinen Einstellungen anlegen.
Taucht diese im Artikelstamm auf, liegt es an dem sogenannten SQL_MODE für neuere MySQL/MariaDB Server. Dann einfach ignorieren.
Passiert dies nicht, wäre es vielleicht doch Zeit sich beim Support zu melden.

und was lernen wir daraus?

Kein Backup, kein Mitleid?