Moin
@cmayer ,
huii, na dann wollen wir mal ;-)
zu Punkt 3:
ja, die Verzögerung kann man in Rewe und in Wawi- Masken des AppDesigners beobachten.
Im Grunde gilt das für alle Eingabefelder und Cursor/Tab- Sprüngen zwischen den Feldern- auffällig wird das aber nur bei längeren Texten.
Die alten Access-Masken haben/hatten das nicht.
Das gilt besonders für die Langtexte oder Dimensionstexte in den Artikel- Stammdaten, für die Memo-Felder bei Artikel oder auch in den Adressen/Kunden/Lieferanten. Erkennbar ist diese "Latenz" aber in allen Feldern.
Besonders störend ist es in der Belegerfassung - unabhängig davon, ob Kopftext, Fußtext, eine Textposition (formatierter Text/unformatierter Text) oder auch dort der Dimensionstext bzw. Langtext.
Wenn Sie wirklich schnell schreiben konnen (10 Finger-System), dann können Sie wirklich erkennen, dass die Buchstaben mit einer gewissen Latenz hinterher- hinken. Diese Latenz ist nicht immer gleich - sie variiert.
Testen kann man das (wenn man nicht so schnell schreiben kann) indem man einen langen Text mit "backspace" löscht. Das geht nicht gleichmäßig - sondern auch hier mit Variierender Latenz. In der Regel trifft man die gewünschte Stelle im Text nicht - man löscht u.U. 1-3 Zeichen zu viel (wegen der Latenz).
Wir müssen hier eindeutig unterscheiden zwischen dem Erfassen (Laden von Sucheinstellungen, Datenklassen, Datenreferenzen etc.) von Daten egal an welcher Stelle und dem Arbeiten in einem bereits erfassten Datensatz, egal ob gespeichert oder nicht. Wenn ich es richtig verstehe, sprechen wir hier immer von dem Bearbeiten eines bereits erfassten Datensatzes innerhalb der Oberfläche. Sprich Ereignisse wie Makros, Validierungen, Aufrufe, Setzen von Feldwerten sind abgeschlossen.
Nehmen wir das genannte Beispiel auf. Es wird ein Dimensionstext eines Artikels innerhalb des MultidataEdit-Elementes geändert. An dieser Stelle findet nur eine Interaktion zwischen Eingabefeld in der Oberfläche und dem KeyInputEvent statt. Beim KeyInput-Event für Texteingabe in Feldern wie Dimensionstexten wird aber kein Ereignis welches eine Latenz erklären könnte ausgelöst, sondern erst beim Verlassen des Feldes.
Ich habe mir einmal in meiner Entwicklungsumgebung die Mühe gemacht, die Netzwerkgeschwindigkeit und sämtliche Ressourcen so stark zu reduzieren bis eine Latenz spürbar war. Diese war dann aber auch in allen anderen Bereichen wie Word etc. bemerkbar. Solange die Latenz auch nicht in Word etc. existiert, kann ich mir diese innerhalb Sage nicht erklären.
zu Punkt 1:
a.) Rewe startet mit ca. 12 Sekunden (vollständiges Regiezentrum, jedoch ohne Dashboard) deutlich schneller wie die Wawi (bei uns ca. 26 Sekunden bis Regiezentrum, ohne Dashboard).
Das mag auch an diversen Zusätzlösungen in der Wawi liegen. Aber auch ohne Zusatzlösungen besteht eine Differenz.
b.) die Stammdatenmasken "Kunden" und "Lieferanten" öffnen sich in etwa der gleichen Geschwindigkeit
die sonstigen Rewe- Masken (etwa Buchungserfassung oder Stammdaten-Sachkonten etc.) öffnen vergleichsweise zügig - und der Wechsel von Datensatz zu Datensatz erfolgt ohne störenden Verzug)
natürlich kann man das nicht mit den Wawi- Masken "Stammdaten-Artikel" oder "Verkaufsbelege bearbeiten" vergleichen weil es um andere Datenmengen geht - aber Reaktionszeit der genannten Rewe- Masken würde ich mir für die genannten Wawi-Masken wünschen.
Eventuell ein erster kleiner Step: Schauen Sie im Server Manager einmal bitte was im Bereich Logging Service bei Umfang der Protokollierung eingestellt ist: Hier reicht für ein Echtsystem aus meiner Sicht Critical oder None, solange keine Fehleranalyse ausgeführt wird.
Anschließend wäre dann auch jeder Punkt im Bereich der Verwaltung Schritt für Schritt durchzugehen, ob die Konfiguration für ihr System geeignet ist. Hier hilft dann nur ein gemeinsamer Termin mit Ihrem Fachhandelspartner oder eigenes Testen unterschiedlicher Einstellungen.
Dass der Start und auch das Arbeiten innerhalb der Masken in Rewe/Wawi unterschiedlich lange dauert ist normal, da einfach die Metadatenbasis im Bereich Rewe deutlich geringer ist, als die in der Warenwirtschaft. Aber das identische Dialoge mit der gleichen Konfiguration eine spürbare Latenz aufweisen, ist mir nicht bekannt. Hier läuft die komplett identische Logik auf identischer Metadatenbasis.
Der Wunsch aller Anwender ist jedoch: "kann man die Sage nicht etwas schneller / flüssiger machen"
Das gleiche höre ich von allen unseren Partnern mit der Sage 9.0.4.
Laut meinen ersten Eindrücken ist die Performance in der 9.05 innerhalb der Warenwirtschaftsdialoge deutlich besser geworden. Sage bemüht sich und tut hier etwas!
Für
Vergleichswerte einmal: Bei optimalen Einstellungen komme ich in meiner Entwicklungs-VM nach dem Klicken auf Anmelden auf 7 Sekunden bis zum Laden des Regiezentrums der Wawi, 4 Sekunden für das erste Initialisieren der VK-Belegerfassung (nach dem Schließen und zweitem Öffnen ist keine Verzögerung bemerkbar) und auf 5 Sekunden für das Laden des Regiezentrums nach dem Klicken auf Anmelden im Rewe.
Mit der tempdb habe ich micht noch nicht beschäftigt (Kompatibilitätsgrad 130, 296MB )
Die tempdb kann in vielen Bereich ausschlaggebend sein. Es wird aber von Sage in den nächsten Wochen ein Leitpfaden zu der optimalen Einstellung eines SQL-Servers herausgegeben. Eventuell warten Sie auf diesen, dann spare ich mir die Tipparbeit ;-)
Ich habe diese nur zur Verdeutlichung der noch zur Zeit bestehenden Komplexität bei CRUD Operationen angehangen bis die Umstellung auf eine Access freie Version abgeschlossen ist. Anschließend wird auch noch die Umstellung auf 64 Bit erfolgen. Für den genannten Fall der Texteingabe siehe oben.
Ich hoffe ich habe nichts wichtiges übersehen. Beste Grüße Rouven
