Abfrage dauert zu lange unter Delphi

[Dumpfbacke]

Zitat:

Zitat von Nersgatt (Beitrag 1285690)

Hängt an der Query noch irgendwas an Ereignissen im AfterOpen, AfterScroll, oder Ähnliches? Oder sind da noch Dinge dran gebunden, wo Ereignisse dran hängen, die lange dauern?

Nein es hängt da nichts dran

[Dumpfbacke]

Zitat:

Zitat von Jasocul (Beitrag 1285695)

Mach doch mal vor dem Open ein DisableControls und hinterher ein EnableControls.

Hat leider nichts gebracht

[Blup]

Wie bereits gesagt, in der Entwicklungsumgebung wird beim Öffnen der Datenmenge nur der erste Datensatz geholt.
Dann unterbricht die Datenbankabfrage.
Um die Gesamtlaufzeit zu ermitteln, muss man zum letzten Datensatz springen.

Zur Laufzeit hängt vermutlich auch ein Grid an der DataSource.
Das fordert nach dem Öffnen mit Standardeinstellungen automatisch so viele Datensätze an, wie derzeit darstellbar sind.

Die lange Laufzeit ist bei der Datenmenge in Kombination mit dieser Abfrage nicht verwunderlich.
Poste uns doch mal den berechneten Ausführungsplan.

[mkinzler]

Bei IN kann auch kein Index greifen. Wenn die Werte mit 'Röhre" beginnen könnte man STARTING WITH statt IN verwenden, dann mit Indexunterstützung.

[p80286]

Ich gehe davon aus, daß das IN hinterher mit mehreren Werten gefüllt ist. Niemand wird ein = durch ein IN ersetzen! (oder doch?)

Gruß
K-H

[tsteinmaurer]

Jegliche Ungleichheitsoperatoren (<>, IS NOT, NOT IN etc.) können in der Regel nicht durch einen Index bedient werden, d.h. der einzige Index der ev. greift ist auf dem Feld "Eingang".

Mich würde primär mal der Ausführungsplan interessieren.

[sx2008]

Und etwas Klarheit zu bekommen würde in Delphi mal folgende Abfrage testen:

SQL-Code:

Select COUNT(*) AS Anzahl
From Material
where Eingang IS NULL and MaterialTyp not in ('Rohre')
and StatusRaus <> 'Auftrag noch nicht erzeugt' and Refernz is not NULL

Diese Abfrage erzeugt auf dem Server annähernd die gleiche Last; allerdings wird nur ein einziger Datensatz an den Client übertragen.
Somit lässt sich erkennen wo der Flaschenhals ist.
Und dann würde ich dir DRINGEND empfehlen das Feld "StatusRaus" als Integerfeld anzulegen.
Überlege dir welche Statuswerte es gibt und welche es in Zukunft noch geben könnte.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1285784)

Bei IN kann auch kein Index greifen.

Wieso nicht? ein 'X IN (A,B)' ist identisch mit 'X=A or X=B' und dann kann sehr wohl ein Index greifen. Vielleicht bei FB nicht, aber nur dann, weil FB an der Stelle schlampt.

Zitat:

Zitat von Blup (Beitrag 1285782)

Wie bereits gesagt, in der Entwicklungsumgebung ...

Zitat:

Zitat von Dumpfbacke (Beitrag 1285688)

...Wenn ich die Query im Objektinspektor ...

Meinst Du mit 'Entwicklungsumgebung' Dinge, wie IBExpert, oder wirklich die Delphi-IDE?

[tsteinmaurer]

Zitat:

Wieso nicht? ein 'X IN (A,B)' ist identisch mit 'X=A or X=B' und dann kann sehr wohl ein Index greifen. Vielleicht bei FB nicht, aber nur dann, weil FB an der Stelle schlampt.

Ne, Firebird schlampt hier nicht und kann bei einem IN Operator (ohne Negation) natürlich einen Index verwenden sofern der Optimizer anhand der Indexstatistiken der Meinung ist, dass der Zugriff über den Index sinnvoll ist.

[Dejan Vu]

Wäre ja wohl auch noch schöner.