![]() |
Datenbank: MySQL • Version: 5.1 • Zugriff über: Zeos
Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Hallo,
in meiner Datenmodul kleben viele Queries, die zur Laufzeit aktualisiert werden. In verschiedenen Forms sind DB-Komponenten (DBEdit etc, aber auch z.B. Jedi DBComboSearchBox). "An sich" ist alles ok. Nur bei einer Query passiert folgendes: das Programm steht für ca. 20 Sekunden, die CPU-Last schnellt nach oben, nichts geht mehr. Nach den 20 Sek. ist die Query durch, alles läuft normal weiter. Jetzt bin ich auf der Suche nach der Ursache bzw. am Nachforschen, was da überhaupt passiert. Ach so: die Query selbst ist's nicht, die braucht 0,... Sekunden wenn ich sie direkt ausführe. In allen anderen Queries machen ich "eigentlich" nichts anderes, da läuft alles fix. Vermutungen: 1) am Dataset der Query hängen irgendwelche Komponenten, die nach einem Update ständig neu über nachgeschaltete OnChange-Ereignisse oä andere Aktionen triggern; an der Query hängt insbes. eine JvComboSearchBox mit einem onchange -> das habe ich soweit möglich händisch kontrolliert und mal alles deaktiviert, kein Unterschied 2) anderer Versuch: mit SendMessage(f_main.Handle, WM_SETREDRAW, 0, 0) die Aktualsierung zu unterbinden 3) über den asmProfiler versucht, etwas mehr Info zu bekommen - leider sagen mir die Ergebnisse nichts, ich kann keinen Bezug zu evtl. aufgerufenen Prozeduren finden Jetzt bin ich wohl ziemlich mit meinem Latein am Ende. "Irgendetwas" läuft da massiv an, wenn die query neue Daten kriegt. Wie komme ich der Ursache auf den Grund? Vielen Dank für eure Tipps! LG Heiko |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Welche Delphi Version nutzt Du?
Seit XE ist ja der AQTime Profiler dabei, der sehr gute Ergebnisse liefert. |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Sorry: hab noch ein "uraltes" D6 prof...
|
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
breakpoint setzen, durchsteppen.
In jeder Zeile in ein Logfile schreiben, mit Zeitstempel, a la "Zeile xy" Vielleicht hast Du auch ein DisableControls irgendwo vergessen. |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Das hab ich gemacht. Ich weiß, dass die Anwendung genau nach query.active := true für 15 Sekunden einfriert und dann wieder ganz normal weitermacht. Und das passiert nach jedem Neuerzeugen der Query.
Ein comboSearchBox.enabled := false graut das angeschlossene Feld zwar aus, ändert aber leider nichts am Einfrieren. Ich müsste irgendwie rausfinden, was intern von Auslösen dieses Events getriggert wird, dh. wer in Folge dessen alles aktiv wird... nur wie? |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Den Hinweis von Furtbichler hast Du aber gelesen?
|
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Zitat:
Ich hätte ein .Open genutzt? (ich geh mal von einem 'Select ..' aus. Zitat:
Das kling alles irgendwie nach "jetzt suchen wir mal in aller Ruhe nach der richtigen DB..." Gruß K-H |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Zitat:
Code:
Ob das so einen großen Unterschied macht?... :dancer2:
procedure TQuery.Open;
begin Active := True; end; |
AW: Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?
Ok, die Verwendung von open und active := true ist damit ja geklärt :)
"Neuerzeugen" ist aber sicher nicht der richtige Ausdruck - die Query wird einmal im Datenmodul erzeugt, aber zur Laufzeit immer wieder mit neuen Parametern an den DBServer geschickt. Und genau DAS dauert dann ewig - wobei die Query selbst nicht das Problem ist, die ist in 0.0xy Sekunden erledigt. Zum Hinweis von Furtbichler: Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz