Hi,
... so viel, so viel neues, wo fange ich an?
1) Das Problem habe ich behoben.
2) Mein erster Instinkt war richtig, habe mich aber von "Zeitmessungen" blenden lassen.
3) Die von Olaf getätigte Aussage:
Lewi hat geschrieben:Sobald das Ergebnis der Abfrage ermittelt wurde, sind die Daten im Speicher.
verwirrt mich, den meine Test zeigen ein zur Aussage nicht passendes Ergebnis. Obwohl ich der Aussage, theoretisch auch zustimmen würde.
4)
Lewi hat geschrieben:wenn Du über hExeCuteQuerry() eine MS-SQL Datenbank abfragst, dann setzt das voraus, dass Du "nativen" Zugriff auf den SQL-Server hast und eine entsprechende Analysis.
Das ist in dem mir vorliegenden Projekt definitiv nicht der fall.
Jetzt mal ein wenig ausführlicher.
zu 4)
Wir haben keinen nativen Treiber für die MS-SQL und keinen für die ADS DB. Das Projekt hat eine Analysis. Auf alle Tabellen (SQL und ADS) wird über einen OLEDB Treiber zugegriffen. Trotzdem wird hier hExecuteQuery(...) verwendet und es funktioniert auch. An den Stellen im Code, wo keine Query sondern ein zuvor zusammengebaute SQL Abfrage ausgeführt werden soll, wird hExecuteSQLQuery(...) verwendet. Das deckt sich also nicht mit der Aussage, dass für die Verwendung von hExecuteQuery(...) ein nativer Treiber vorhanden sein muss.
Zu 3)
Der Aussage von Olaf würde ich auch so zustimmen. Wie soll es denn auch anders sein? Aber in meinem Fall scheint etwas anders zu laufen. Denn ich messe die Zeit für das Ausführen von hExecuteQuery(...) und stelle fest, dass die Abfrage, je nach Netzauslastung zwischen 1-2 Sek. braucht. Das ist in Ordnung. Danach greife ich auf das Ergebnis zu und messe wiederum die Zeit. Sind die Daten bereits im Speicher, sollte es hier zu keinen größeren Verzögerungen kommen. Aber bei mir dauert der Erste Zugriff auf das Ergebnis, gemessene 20 - 60 Sek. und zwar unabhängig von der Anzahl der Datensätze, also auch bei einem. Ist der erste Satz gelesen, läuft alles in Sekundenbruchteilen durch. Die Verzögerung ist für die Anwendung nicht akzeptabel.
Zu 2 und 1)
Als ich das Projekt bekommen habe um die Performance zu verbessern, habe ich spontan gesagt: "Liegt mit hoher Wahrscheinlichkeit an nicht optimierten Datenbankzugriffen". Das ist zumindest - aus meiner Erfahrung - in den meisten Fällen, die ich bis dato bearbeitet habe der Fall und zwar unabhängig von Programmiersprache und System.
Deshalb habe ich die Zeit gemessen und war mit den 1-2 Sek. für die Abfrage zufrieden. Leider stimmte damit meine vorher getätigte Aussage nicht und ich musste weiter suchen.
Die Engstelle habe ich aber recht rasch ausfindig gemacht. Wir in vorherigem Post geschrieben, stockte immer der erste Zugriff auf das Ergebnis des Querys. Was also machen? Nach vielen erfolglosen Versuchen, habe ich es einen Tag liegen gelassen und dann mit vielleicht neuen Ideen dran zu gehen.
Ich fing also wieder von Vorne an. Und da ich aus der eigenen Erfahrung her sagen kann, dass die Engstellen zu geschätzten 90 - 65% der Fälle, schlecht programmierte DB Abfragen sind, schaute ich mir den Query genauer an, obwohl die Zeitmessung an dieser Stelle in Ordnung war.
Im Query wurden Daten aus zwei Tabellen geholt. Verknüpft mit einem Join. Das Fatale, die eine Tabelle liegt auf dem MS-SQL, die andere auf dem ADS Server. Auf beide erfolgt der Zugriff per OLEDB. Ich habe testweise den Query umgebaut, so dass ich nicht in einer Abfrage auf zwei Tabellen, auf zwei unterschiedlichen Servern zugreifen muss und die Where Klausen optimiert.
Das Ergebnis ist jetzt so wie man es erwarten würde. Die Ausführung des Query dauert einen Augenblick, danach - also beim Zugriff auf die gelieferten Daten - gibt es keine relevante Verzögerung mehr. Somit ist das Problem erledigt, es bleiben aber Fragen offen. Vielleicht war in meinen Fall das Konstrukt so untypisch, dass es solche (unvorhersehbare?) Folgen hatte.
Zumindest stimmt somit meine erste Diagnose.
P.S. Statt mit Trace() die gemessene Zeit auszugeben, kann man natürlich auch die WinDev Funktionalität unter Project->Performance profiler nutzen. Den Punkt habe ich aber erst später entdeckt.