Verkaufsaufträge Speichern

[unisoft ah]

Bei grossen Aufträgen oder Aufträgen mit wenig Positionen aber z.B. 1000 Seriennumern kann es sein, dass bei Speichern / Verarbeiten Positionen verloren gehen. Der Grund dürfte sein, dass der Benutzer nicht die nötige Gedult aufbringt, oder in seltenen Fällen, das System (Windows) aus irgend einem Grund abstürzt.

Ein Kunde hat es so beschrieben:
Der Originalauftrag hatte 12 Positionen, zum Zeitpunkt der Meldung waren es noch deren Zwei.
Während dem speichern, stürzt der Mentor ab oder benötigte so lange zum speichern, bis der PC heruntergefahren wurde.
Da in dem Auftrag vier grössere Positionen mit Seriennummern vorhanden sind, dauert das speichern des Auftrages.
Den Auftrag mit 1100 Seriennummern zu speichern dauert bei meinem relativ performanten PC ca. 1Minute und 30Sekunden.
Gemäss SQL-Protokoll, löscht Mentor beim Speichern den Auftrag zuerst komplett aus der Datenbank und erstellt diesen neu.
Dies hat den Einfluss, dass bei einem Systemabsturz während des Speicherns, ein Datenverlust auftritt.
Glücklicherweise wurde der Fehler bemerkt. Wäre dieser Auftrag nicht nochmals kontrolliert worden, hätten wir Material von mehreren 10'000 Franken verschenkt.
Der Fehler wäre vor allem nicht mehr nachvollziehbar gewesen.

Eine Umstellung auf SQL-Transaktionen wäre eine sinnvolle Erneuerung.

Aus unserer Sicht:
Natürlich ist es ein Problem, welches eher selten auftritt.
Aus meiner Sicht könnte mit einer Fortschrittsanzeige, «Ihr Auftrag wird verarbeitet» angezeigt werden, dass das System an der Bearbeitung des Auftrages ist.
Während dieses Prozesses könnten dann auch keine Anderen Aktionen gestartet werden – ausser Abbrechen – wobei in diesem Fall wieder der Auftrag angezeigt werden sollte.

Oder siehst Du eine andere Methode wie dieser Fall des Abbruchs oder des Abstürzens während dem Speichern eines Auftrages begegnet werden könnte?

[Kaiser]

1. Der Kunde spricht von "Abstürzen". Wir können nichts dagegen unternehmen, wenn beim Benutzer der Task oder der ganze Computer aus irgendeinem Grund abstürzt.

2. SQL-Transaktionen mit Rollback wirksam einzusetzen, würde die Performance der Datenbank beeinträchtigen.

3. Die maximale Anzahl Positionen pro Verkaufsauftrag beträgt 1000. Während des Abspeicherns eines Auftrags wird die Sanduhr angezeigt.

4. Einen Verkaufsauftrag mit 1100 Serienummern abzuspeichern, dauert hier 9 Sekunden (und nicht 1 Minute, 30 Sekunden). Auch hier wird die Sanduhr angezeigt, bis der Auftrag fertig abgespeichert ist.

Genügt dem Benutzer die Sanduhr nicht? Wenn während der Sanduhr ein Schliessen erzwungen wird (durch wiederholtes Anklicken des Schliessenknopfes), meldet Windows, dass die Applikation momentan nicht reagiert. Die Applikation müsste dann mit "Programm schliessen" abgebrochen werden. Ein irrtümliches Schliessen während des Speicherns kann also ausgeschlossen werden.

[unisoft ah]

Zu 1.) Ja, das gegen den Absturz an sich nichts unternommen werden kann sehe ich auch so. Gewünscht wäre, dass auch im Absturz-Fall die Daten eines Auftrages nicht verloren gehen.

Zu 2.) Auch wenn SQL-Transaktionen mit Rollback die Performance beeinträchtigen würde, wäre dieser Ansatz aus unserer Sicht wünschenswert.

Zu 3.) Ok - Was passiert wenn der Benutzer mehr als 1000 Positionen erfasst?

Zu 4.) Ich finde 9 Sekunden mit 1100 Seriennummern ausgezeichnet.

Ich weiss nicht, wie Du mit Deinem System auf 9 Sekunden kommst, resp. was der Unterschied in der Umgebung ist.
Die Kunden arbeiten mit MySQL 5.5.50 oder auch MySQL 5.5.10 - in der 64 Bit Variante.
Die DB ist immer auf einem Windows Server mit Windows Server Standard 2013 / 2016 oder 2019.
Das Datadir ist eine Netzwerkfreigabe.
Die Tabellen sind im Format MyISAM.
Der Zugriff erfolgt über das Netzwerk mit 1000/1000 (Mbps)
Die Clients haben Windows 10 Pro und 16 GB Arbeitsstpeicher und meist eine SSD.

Wir kommen bei keinem System auf diese Zeiten - und bewegen uns schon eher im Bereich von einer Minute.
Kann es sein, dass wenn die verschiedenen Tabellen schon z.B. 250'000 Aufträge und 700'000 Positionen haben sich dann anders verhalten?
Oder hat es einen Zusammenhang mit der Tabelle Syst_Text?

Betreffend der Sanduhr:
Eine Fortschittsanzeige wäre besser als die Sanduhr. Wenn der Benutzer den Fortschritt sieht, dann kommt er nicht auf die Idee, dass sich das System aufgehängt haben könnte. Der Benutzer sieht dann, dass etwas "läuft".

Z.B. gibt es Benutzer, die beim Jahresabschluss der Fibu bei Punkt Saldi Übertragen nochmals auf den Knopf klicken, da "irgedwie nichts passiert", und der Kunde nicht sicher ist ob er beim ersten Mal "richtig geklickt" hat. Dann erhält der Benutzer 2 x die Eröffnungsbuchungen.

Beim Verkaufsauftrag kann der Kunde auf die Idee kommen, dass sich das System aufgehängt hat, dann versucht er das Mentor mit dem X zu schliessen. In diesem Fall, gehen die Positionen verloren.

[Kaiser]

1.) und 2.) Nach all den Diskussionen, die wir immer wieder betreffend Antwortzeiten haben, macht das keinen Sinn.

3.) Der Benutzer kann gar nicht mehr als 1000 Positionen erfassen, weil eine entsprechende Fehlermeldung erscheint.

4.) Wir haben tatsächlich zeitgemässe Maschinen (32 und 64 GB Arbeitsspeicher, nicht 16). Die Grösse der Datenbank spielt natürlich auch eine Rolle, daher empfehlen wir, mit der Wartung alte Daten abzuwerfen.

5.) Jahresabschluss Fibu - Saldi übertragen: Hier erscheint eine Fortschrittsanzeige! Weshalb drücken die Benutzer dann den Knopf zweimal?

6.) Gegen das "Gefühl", dass sich eine Applikation "aufgehängt" hat, hilft vor allem Schulung. Wie wir bei Punkt 5.) sehen, passiert das auch bei einer Fortschrittsanzeige.

[Kaiser]

Wir können beim Speichern der Aufträge eine Fortschrittsanzeige einbauen, aber...

1.) Wird das gegen ungeduldige Benutzer, die gerne eine Applikation abschiessen, obwohl diese noch am arbeiten ist, nichts nützen (siehe dazu auch "Fibu-Abschluss").

2.) Müssten wir das bedingen, so dass bei kleineren Aufträgen keine Fortschrittsanzeige erfolgt (beispielsweise unter 100 Positionen/Serienummern). Die Fortschrittsanzeige verbraucht nämlich auch Ressourcen und Zeit.

3.) Wären wir dankbar, wenn du dazu ein neues Thema erfassen würdest.

PS zur Verarbeitungsgeschwindigkeit: Wir betonen zur Sicherheit nochmals, dass solche Messungen nur ohne Protokoll erfolgen dürfen. Dieses verbraucht nämlich extrem viel Verarbeitungszeit.

[unisoft ah]

Zuerst die Antworten auf den ersten Deiner beiden Einträge:

1.) und 2.) Betreffend SQL-Transaktionen mit Rollback - versus Geschwindigkeit.
Unbestritten, dass ist ein Widerspruch.
Natürlich ist gute Performance immer gewünscht. Ich gewichte aber Sicherheit, also auch im Crash Fall keinen Datenverlust höher.
Daher habe ich geschrieben, dass SQL Transaktionen mit Rollback wünschenswert wären.

3.) Gut, wenn mehr als 1000 Positionen erfasst wurden erscheint eine entsprechende Meldung.

4.) Memory hat einen Einfluss, im Besonderen was mindestens an Memory vorhanden sein muss. Bei einer Client-Server Installation ist es aber m.E. nur ein Element. Wir haben gerade bei einem Kunden von 8 GB auf 32 GB erweitert und irgendwie keinen wirklichen Unterschied in der Performance feststellen können.
Mit der Wartung "alte" Daten abwerfen wäre definitiv die beste Lösung.
Das haben meine Kunden von mir auch schon oft gehört...
Nur scheint dies eher ein Ding der Unmöglichkeit.
Gerade die Kunden mit Traktoren etc. argumentieren, dass diese Maschinen bis zu 25 Jahre im Einsatz sind, und dass Sie daher die Daten weiterhin haben wollen (Geschichte was repariert wurde). Auch hier sehe ich das es beiden Ansichten gibt...
Ich habe in unserem eigenen Mandanten auch alle Daten drin seit 2002...
Tendenziell sind den Kunden die alten Daten mehr wert als z.B. 3 Sekunden - scheinbar ist das so.

5. Jahresabschluss - Ja, es gibt eine Fortschrittsanzeige. Bei einer Kundendatenbank habe ich dies soeben ausprobiert. Wenn ich beim Abschluss den Punkt 4. Drucken provisorische Bilanz anklicke sehe ich zuerst 60 Sekunden die Sanduhr resp. das - drehende Kreissymbol - (und dann keine Rückmeldung) anschliessend startet die Fortschrittsanzeige.
Beim Punkt 8. Abschluss und Saldi Übertragen stelle ich fest, dass Du recht hast, hier erscheint die Anzeige sofort und interessanterweise ging dies bei diesem Mandanten auch innert 5 Sekunden.
Der Index ist gemäss dem Forum Datenbank: Tabelle "Fibu_Buchung" / Index 1: Felder "Konto, Datum, Beleg, Buchung"
Ich hatte das anders beobachtet - Wenn es jetzt so schnell und direkt ist - bei Punkt 8 (wie oben beschrieben) - dann sehe ich da keinen Handlungsbedarf – das ist bestens.
Da frage ich mich e bei dem Beispiel oben

6. Ja, Schulung ist sicher ein Faktor. Ich erkläre den Kunden jeweils, dass Sie warten müssen, wenn die Sanduhr erscheint - das bedeutet ja eigentlich nichts anderes als dass die Aufgabe in Bearbeitung ist.

[unisoft ah]

Betreffend: Wir können beim Speichern der Aufträge eine Fortschrittsanzeige einbauen, aber...

1.) Ja, gegen ungeduldige und Beratungsresistente Benutzer wird es nichts nützen. Es hat aber auch einen psychologischen Effekt - wenn der Anwender sieht, dass sich "etwas bewegt" also eine Fortschrittsanzeige ist der Anwender eher bereit zu warten.

2.) Ja, das leuchtet mir ein und ist sinnvoll.

3.) Ja, gerne erfasse ich ein neues Thema.

P.S. Ja, die Messungen waren ohne Protokoll. Ich würde Dir gerne eine Datenbank zur Verfügung stellen - mit so einem grossen Auftrag. Weil es wäre schon interessant, wieviel Ziet Dein System braucht, und wiviel unser Sytem - resp. wo wir etwas optimieren könnten.

[Kaiser]

Merci für das neuerfasste Thema.

Betreffend SQL-Transaktionen: Einfache Transaktionen mit Rollback sind für den Fall gedacht, dass der Server abstürzt. Hier ist es aber so, dass der ungeduldige Benutzer eine Verarbeitung bewusst abbricht. Dazu müsste das herkömmliche Rollback-System erweitert werden - sprich: beim Wiederaufstarten des Clients müsste geprüft werden, ob eine Transaktion unerledigt geblieben ist, danach müsste eine umfangreiche Undo-Funktion gestartet werden. Wenn da bis zum Wiederaufstarten einige Zeit verstreicht, wird das sehr, sehr heikel! (Andere Benutzer haben ev. in der Zwischenzeit den betreffenden Auftrag bearbeitet.)

Zudem kann mit bis zu einer Verdoppelung der Antwortzeiten gerechnet werden, das will kein Mensch. Und das alles, weil ein Benutzer trotz laufender Sanduhr (!) die Applikation abwürgt.

Glaub mir, ein solches SQL-Transaktionssystem wollen unsere Kunden nicht.

[unisoft ah]

Danke für die Erklärung.
Ich verstehe nun das Problem besser.
Im besonderen das der Client "den Faden" wieder aufnehmen müsste ist echt problematisch.
Somit - Du hast mich überzeugt!

[Kaiser]

Merci für dein Verständnis.

[Kaiser]

Update!

Während der Verarbeitung des Buchhaltungsabschlusses werden die Knöpfe "Ok" und "Zurück" deaktiviert.

Der Update ist auf der Webseite Mentor verfügbar.

[unisoft ah]

Besten Dank.

[Kaiser]

In den Systemeinstellungen kann der Grenzwert eingestellt werden, so dass sowohl Kunden mit schnellen als auch solche mit langsamen Netzwerken diese Funktion optimal nutzen können.

Siehe Fortschrittsanzeige bei grossen Aufträgen