Problem Kassenbuchung sehr langsam

Hallo,

ich stehe vor folgendem Problem:

Nach jedem Kassiervorgang dauert es seit ein paar Tagen nach dem Rücken der Taste "buchen" in der Kasse sehr lange, bis der Bon erstellt wird und die Schublade öffnet.
Der Vorgang dauert nach dem "buchen" ca. 10 Sekunden, davor sprang die Kasse quasi sofort auf.

Das passiert nur in einer Filiale, der mit den meisten Kunden und Umsatz, bei den anderen ist alles OK. Hardware ist überall gleich. Um Hardwarefehler auszuschließen, habe ich eine
Ersatzkasse mit Drucker und Schublade aufgebaut - Ergebnis bleibt mit der DB gleich langsam.

mysql ini ist in allen Filialen gleich

CAO Admin zeigt im DB Check überall "OK" an, mit einer anderen "Schulungs"Datenbank rennt die Kasse wie früher super!
CAO selber ist auch schnell und flüssig.

-> CAO-Kasse Version 1.4.3.6 F (die mitgelieferte der CAO V 1.4.3.8 K)
-> DB ist original, also keine eigenen Tabellen, kein rumgehacke in der DB
-> mysql läuft lokal (localhost) also kein Netzwerkproblem
-> Hardwareproblem schließe ich wie oben getestet auch aus
-> Das Problem tritt nur an der Kasse auf und nur beim buchen (genau da wo es auf Zeit ankommt, wir haben viele Kunden mit kleinen Beträgen)
-> Das Problem liegt an der spezifischen Datenbank (in Ordner mysql/data ist die DB ca. 175 MB groß) reparieren / optimieren brachte nichts - kann ja auch nicht da alles "OK"
-> Wir nutzen CAO seit 2007 und es sind natürlich viele Daten in den Journalen....

Wer hat ähnliches festgestellt und kann helfen?
Gibt es eine Funktion in CAO um die alten Journaldaten zu löschen? Ich könnte auf 2007 - 2009 oder 2010 verzichten und würde das gerne testen!

Was könnte ich noch ausprobieren um den Fehler einzugrenzen? Bin für jede Idee und Hilfe dankbar!

Beste Grüße!

Ich hatte ein ähnliches Problem das allerdings netzwerkbedingt war. Ich weiss das du dies ausschliesst, dennoch möchte ich es mal erzählen. Vielleicht hilfts einem anderen Leser...

Als ich einige Videoüberwachungsgeräte im Laden installiert habe, hatte ich diese zuerst über unser Wireless Netzwerk laufen, das war dann scheinbar so ausgelastet dass CAO hinten anstehen musste. Zuerst hatte ich dann diese Kasse ans Netzwerk gehängt und dann lief das wieder recht flüssig.

Zu deinem Problem: Schonmal Firewall/Antivirenprogramme kurzfristig deaktiviert? Habt ihr vor 10 Tagen etwas neu installiert? Findet man gut unter "Programm deinstallieren" und dann nach Installationsdatum sortieren.

Hi Wuffli,

danke für den Hinweis!

Firewall und Virescanner hatte ich aus, keine Änderung - hatte ich vergessen zu schreiben!

Es wurde nichts neu installiert und die DB ist auf einem zweiten PC auch so langsam.
Habe eben auf dem Testsystem mit der DB mysql 4.1.22 installiert - leider auch kein Erfolg.... - schnief -

Hast du ein Backup von einem Zeitpunkt als alles noch i.O. lief? Dieses schonmal ausprobiert? Wenn dass das Problem löst wissen wir wenigstens in welchem Bereich zu suchen ist...

Hallo,

wird während der ominösen 10 Sek. auf der Platte rumgeackert oder hängt das System einfach?

Ich hatte mal den Fall, dass ein Datensatz trotz "Reparieren" Datenmüll enthielt.
ich habe das mit HeidiSQL und durchsehen aller Tabellen rausgefunden.

Hallo,

vielen Dank für Eure Hinweise!

Die o.g. Schulungsdatenbank, ist eine Kopie der original DB, jedoch mit weniger historischen Daten!
Das System nutzt zwar während der Wartezeit die Festplatte, aber die LED blinkt nur leicht, es wird also nicht die ganze
Zeit "herumgeackert" :-)

Ich habe sogar mal die Tabellenstrktur verglichen um einen Fehler beim Update auszuschließen, auch hier sind alle
Felder identisch beschrieben.

Alle Felder mit SQLFront o.ä. durchzusuchen ist irgendwie keine Option, alleine der Journalpos hat um die 280000 Einträge...
Ich habe jetzt mal im Testsystem die einzelnen Tabellen in der mysql/data durch die der Schulungsdatenbank ersetzt.

Es liegt an der Tabelle journal! Wenn ich die aus dem Testsystem nehme ist das System wieder schnell....

Also nun mal händisch den Journal von fast 6 Jahren durchgehen...

JIPPIE!!

Danke für Eure Hilfe, das hat den richtigen Denkanstoß gegeben!

Nachdem klar war, dass es die Tabelle journal war, habe ich das Problem mit folgendem Programmaufruf in mysql/bin gelöst:

mysqlcheck cao_db_name journal --repair -uroot -ppasswort -hlocalhost -e -f --tables

Der Aufruf hat ca. 1 Minute gedauert und nun "rennt" unsere Kasse wieder und die Kollegen mögen mich auch wieder :-)

Ehre gerettet, Mission erfüllt, gratuliere!