Schlechte Perfomanz bei TQuery

[Stephan Schneider]

Hallo,

Umg.: Delphi 6 Ent. UP2, BDE 5.2.0.2, Paradox, MSSQL2000

In einer Anwendung wird für den Erhalt einer Ergebnismenge eine TQuery verwendet, um das im Datenmodell verankerte Generalisierungskonstrukt zu erfassen (mit TTable wäre das nicht möglich). Der SQL-Befehlt besteht aus:<pre><code>select Table1.ID, Table1.LastUpdate, Table2.ID, Table2.Description, Table2.X usw.<br>from Table1, Table2<br>where Table2.ID = Table1.ID<pre></code>

Das bloße Öffnen dieser Abfrage dauert ewig. Beinhalten die entsprechenden Paradoxtabellen einige hundert Einträge, so dauert das Öffnen ungefähr 17 Sekunden.

Wie kann ich die Perfomanz bei TQuery deutlich erhöhen?

Danke<br>Stephan

[Bernhard Geyer]

Sind entsprechende Indexs auf Tabelle1 und Tabelle2 auf das Feld ID gelegt?

Verwende Inner-Joins:

SELECT ....
FROM Table1 INNER JOIN Table2 on Table1.ID = Table2.ID.

Kann aber sein das Paradox über die BDE nicht kann.
Falls nicht: Schmeiß BDE und Paradox weg und leg dir 'ne vernünftige Lokale Datenbank zu (Absolut Database, TurboDB, ADS Local Server, ...

[Stephan Schneider]

Hi Bernhard,

ja, alle Tabellen sind indiziert.

Ich kann die BDE und Paradox leider nicht wegschmeißen, da ich diese über die Jahre gewachsene Applikationswelt weiter entwickeln soll/muss. Ich habe bereits vor etlichen Jahren die BDE/Paradox für nicht so geeignet erklärt, aber da dies nicht nur meine Entscheidung war, muss man jetzt notgedrungen damit leben. Aber ein Rennpferd werde ich aus diesem Gespann auch nicht machen können

[Mario.Noack]

Versuche mal den SQL direkt in Paradox. Wenn dort das gleiche "Problem" auftritt, ist der SQL nicht optimal, die Datenmenge zu groß, die Indizes nicht existent oder oder oder.<p>
Ein Join wird Dir keinen Zeitvorteil bringen, auch wenn es die BDE kann. Prüfe ausserdem, wo das Arbeitsverzeichnis (privatdir?) liegt. Nicht dass die BDE die Query auf dem Netz aufbaut?<p>
Mari

[Stephan Schneider]

@Mario

Mit "versuche mal den SQL direkt in Paradox" meinst Du wahrscheinlich dessen Ausführung in der Datenbankoberfläche?!

Wenn ich dort denselbsen SQL-Befehl ausführe (per copy & paste reinkopiert), dann erscheint das Ergebnis binnen kürzester Zeit. Das lässt mich schon mal hoffen.

In der Anwendung selbst dauert die Ausführung wesentlich länger. Zum Vergleich: In der Anwendung ca. 17 Sekunden, in der Datenbankoberfläche ca. 2 Sekunden.

Die wesentlichen Einstellungen der Query in der App:
AutoCalcFields=True
AutoRefresh=False
CachedUpdates=True
Constrained=False
ObjectView=False
RequestLive=False
UniDirectional=False
UpdateMode=upWhereAll

Als UpdateObject hängt eine eigene von TUpdateSQL abgeleitete Komponente dran, die ein paar Unzulänglichkeiten der originären Komponente ausmerzt. Ich kann mir nicht vorstellen, dass die der Performancekiller ist.
<br>
Das PrivateDir wird zur Laufzeit auf ein lokales Verzeichnis gesetzt

[Mario.Noack]

Dann hänge zum Test noch mal die DataSource ab. Wenn das hilft, musst Du die drangehängten Controls checken.<p>
Mari

[Stephan Schneider]

Leider keine Verbesserung :-(

Am Ende der Datasource hängt ein ExpressQuantumGrid der neuesten Version 5.10. Zuerst dachte ich, das Grid wäre ein heißer Kandidat für den Perfomance-Verlust-Preis. Aber das Ausführen der Query alleine verbraucht schon dermaßen viel Zeit, so dass ich gegenwärtig an das Grid (noch) gar nicht denken brauche.

Zusammenfassung:<br>Die Ausführung des SQL-Codes in der Datenbankoberfläche zeigt sich als sehr schnell (ca. 2 Sekunden)<br>Ausführen desselben SQL-Codes via einer TQuery in der App erweist sich als laaaaaaaangsam (ca. 17 Sekunden), und das Ganze ohne Datasource.

Nun ist guter Rat teuer.

Stepha

[Heiko Luettge]

Hallo Stephan,<p>

Dauert denn das Query.Open wirklich solange (Debugger), oder die nachfolgenden Aktionen.<p>
wie gross ist denn das Ergebnis (Zeilenzahl)<br>
kann man das Ergebnis nicht verkleinern (mit einem Where)
<p>
Unidirectional=true
AutoCalcFields auf false, wenn es nicht benötigt wird
<p>
Baue das sql-statement in ein NEUES Query Objekt ein, dann
Button aus Form, Query.Open
<p>
Das Quantum hat auch ein BeginUpdate/Endupdate Mechanismus
<p>
Und zu guter letzt, warum geht es nicht mit TTable (also alle Datensätze von Tabell1 laden in eine Lioste, dann alle von Tabeöe 2 in eine 2. Liste, und dann lokal zusammenbauen?<br>
Query ist zwar einfacher, aber halt sehr langsamer
<p>
Heiko<br>
Der zum Glück weg von Paradox is

[Stephan Schneider]

Ich habe zu Testzwecken ein einfaches Form erstellt, das im OnFormCreate() die Query öffnet. Mehr passiert in diesem Fenster nicht, keine Datasource, keine db-sensitiven Controls. Nichts, nothing, niente, nada, nur das Open() der Query.

Das Ergebnis umfasst ca. 2000 Datensätze, also wahrlich nicht die Welt. Wie gesagt, ich dachte zuerst auch an irgendwelche Controls, vornhemlich das QuantumGrid. Aber mein einfacher Test mit der simplen Form hat mich eines besseren belehrt. Das BeginUpdate/EndUpdate des EQG ist mir bekannt, und funktioniert im unbound mode super. Da ist der Performancegewinn schlichtweg der helle Wahnsinn. Aber nicht im DB-Mode.

Warum es nicht mit TTable geht, ist schnell erklärt. Ich kann ein Generalisierungskonstrukt im Datenmodell mit TTable einfach nicht erfassen. Mit TQuery kann man es erfassen, aber die Update-Mechanismen können dies auch wieder nicht. Daher habe ich mir eine eigene TUpdateSQL Komponente gebastelt (schon vor langer Zeit), die Updates (INSERT, DELETE, UPDATE) auch unter Bezug auf mehrere Tabellen erlaubt. Somit kann ich super derartige Gegebenheiten eines Datenmodells adäuqat einkapseln. Natürlich könnte ich entsprechend Deinem Verfahren vorgehen, nur dann nehme ich mir die Möglichkeit, das Grid direkt an eine Datasource zu binden.

Ich glaube mittlerweile auch nicht, dass es irgendetwas mit dem Grid zu tun hat (siehe meinen einfachen Test mit der simplen Form ohne db-aware Controls). Das bloße Open() der Query dauert in der App solange. Und da wird ja nur das SELECT ausgeführt, das wiederum in der Datenbankoberfläche wesentlich schneller geht (17 Sekunden vs. 2 Sekunden)

[Heiko Luettge]

Hallo Stephan,
nimm mal das normale TQuery, nicht dein eigenes.
Vielleicht wird ja irgendein Ereignis in deiner eigenen Komponente aufgerufen.

Ich kann dir auch mal ein kleines Tool schicken (sql-it), wo man ein SQL-Statement eintragen kann, was dann in einem Grid angezueigt wird (das Ergebnis natürlich).

Es wird nur TQuery benutzt.

Heik