Clientseitiges Performanceproblem nach Query-Update- Fehlersuche, wie?

[baurat]

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

[daywalker9]

Welche Delphi Version nutzt Du?

Seit XE ist ja der AQTime Profiler dabei, der sehr gute Ergebnisse liefert.

[baurat]

Sorry: hab noch ein "uraltes" D6 prof...

[Furtbichler]

breakpoint setzen, durchsteppen.
In jeder Zeile in ein Logfile schreiben, mit Zeitstempel, a la "Zeile xy"

Vielleicht hast Du auch ein DisableControls irgendwo vergessen.

[baurat]

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?

[vagtler]

Den Hinweis von Furtbichler hast Du aber gelesen?

[p80286]

Zitat von baurat:

Ich weiß, dass die Anwendung genau nach query.active := true für 15 Sekunden einfriert ...

Und wofür ist das gut?
Ich hätte ein .Open genutzt? (ich geh mal von einem 'Select ..' aus.

Zitat von baurat:

Und das passiert nach jedem Neuerzeugen der Query.

Was bitte ist ein "Neuerzeugen"?

Das kling alles irgendwie nach "jetzt suchen wir mal in aller Ruhe nach der richtigen DB..."

Gruß
K-H

[vagtler]

Zitat von p80286:

[...] Ich hätte ein .Open genutzt? [...]

Code:

procedure TQuery.Open;
begin
  Active := True;
end;

Ob das so einen großen Unterschied macht?...

[baurat]

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:

breakpoint setzen, durchsteppen.
In jeder Zeile in ein Logfile schreiben, mit Zeitstempel, a la "Zeile xy"

Vielleicht bin ich zu unwissend, wie man mit dem Debugger richtig arbeitet - beim Durchsteppen springt er mir in den ganzen Datenbank-Klassen kreuz und quer, für mich wenig erhellend - und ich kann dabei nicht erkennen, wann ein Ereignis außerhalb des gerade betrachteten Quelltexts gefeuert wird (oder doch?).

Zitat:

Vielleicht hast Du auch ein DisableControls irgendwo vergessen.

Versucht: problemquery.disableControls, dann problemquery.open () und dann wieder problemquery.enableControls - leider das gleiche...