Hallo Leute, ich habe mal wieder ein Problem, an dem ich arbeite:

Für die schnellere Verarbeitung habe ich Datenbanktabelleneiträge in Listobjekte überführt. Warum? Ich muss mit mehreren chemischen Analysen (gespeichert in Master-Detail-Tabellen (1:n-Zuordnung)) Rechgnungen durchführen. Dabei müsste ich auf Seiten der Datenbank ständig Datensätze wechseln. Das habe ich umgangen, indem ich die relevanten Daten in Objekte überführe und dort die Operationen (Driftkorrektur, Werteanpassungen ...) durchzuführen. Nun habe ich aber immer wieder den Effekt, dass manche Datentabellen zum Öffnen geschlagene 51 Sekunden benötigen, mache ich die gleiche Operation zu einem anderen Zeitpunkt nochmals, geht das in 50 ms. Das treibt mich echt zur Verzweiflung. Ich habe schon festgestellt, dass bei manchen Tabellen, die über TQuery angesteuert werden, eine Vorfilterung in der Datenbankunit (alle Tabellen werden in dieser verwaltet), die Öffnung später - mit anderer Filterung - sehr beschleunigt. Doch das hilft mir bei der Analysendatentabelle nicht weiter. Diese wird nach den aktuellen Analysen gefiltert und den dazugehörenden Referenzmessungen. Die Originaltabellen (ungefiltert) haben, um den Umfang darzustellen, als Master 25600 Datensätze, und als Detail 634000 Datensätze.

Es ist eine Access-Datenbank, angesteuert über ODBC (Bitte jetzt keine Diskussion über Schnelligkeit der ODBC-Ansteuerung, das weiß ich selber, aber so komme ich besser mit dem Ganzen klar, zumal ich ja auch noch Auftragsdaten und Adcressdaten damit verknüpfe, Analysenberichte damit erzeuge etc.

Hat jemand eine Idee, wie es zu dermaßen unterschiedlichen Zugriffszeiten kommen kann. Ich versuche mal, die Fehlerquelle genauer einzugrenzen, doch das - obwohl ich viele Routinen protokolliere - ist recht aufwändig.

Danke im voraus schon mal für eine Idee, vielleicht auch bezüglich Vorgaben von TQuery.

Gunther Troost hat folgendes geschrieben :

Nun habe ich aber immer wieder den Effekt, dass manche Datentabellen zum Öffnen geschlagene 51 Sekunden benötigen, mache ich die gleiche Operation zu einem anderen Zeitpunkt nochmals, geht das in 50 ms.

Bist du dir ganz sicher, dass es sich wirklich um die selbe Operation mit den selben Daten handelt? Auch Kleinigkeiten können zu erheblichen einbußen führen.

Bei Access gibt es einige Möglichkeiten zu optimieren. Mit den paar Informationen ist es aber schwierig, gute Tipps zu geben.
Daher solltest du vielleicht erstmal diesen Link abarbeiten:
https://dbwiki.net/wiki/Access_Performance-Tipps

Ergänzung:
Öffnest du die Tabellen in einem Master-Detail-Konzept?
Falls das so ist, solltest du das Konzept ändern. Soweit ich weiß, arbeitet dieses Konzept mit Filtern. D.h.: Es werden alle Daten der "Details" geladen und über das verknüpfte Feld gefiltert. Wenn dann das Feld nicht indiziert ist, geht die Performance in den Keller.
Je nach Master-Start-Wert, können dann die Zeiten beim Öffnen der Tabellen entsprechend unterschiedlich sein.

Die Tabellen sind in Access wie folgt miteinander verknüpft:

Master: Feld Nr(long integer, indiziert (ohne Dubletten), Primärindex)
Detail: Feld Nr(long integer, nicht indiziert)

Verknüfungstyp: Jeweils nur die Datensätze, in denen beide Tabellen den gleichen Wert haben. (1:n) Mit referentieller Integrität und Aktualisierungs- und Löschweitergabe

Das Feld Nr aus Master ist kein Autowertfeld. Das liegt daran, dass ich die Daten aus alten DBase-Datentabellen erzeugt hatte. Macht Autowert in der Frage etwas anderes?


Zu der anderen Frage mit den gleichen Datensätzen: Ja, da bin ich mir sicher, weil ich mehrfach hintereinander die gleiche Operation an dem gleichen Datensatz mache. Mal dauert es ewig lange, mal geht es ausreichend schnell. Auch in dem Protokoll sehe ich dann die gleichen aufgerufenen Prozeduren.

Die Strukturen in Access sind so schon richtig. Ich hätte das klarer formulieren sollen. Wenn du in Delphi mit Master-Detail-Verbindungen arbeitest, kann das zu Performance-Problemen führen.
Aber ich denke, dass das hier ein anderes Problem ist.

Gunther Troost hat folgendes geschrieben :

Zu der anderen Frage mit den gleichen Datensätzen: Ja, da bin ich mir sicher, weil ich mehrfach hintereinander die gleiche Operation an dem gleichen Datensatz mache. Mal dauert es ewig lange, mal geht es ausreichend schnell. Auch in dem Protokoll sehe ich dann die gleichen aufgerufenen Prozeduren.

Das klingt für mich so, als würde sich die Datenbank die Abfragen merken. Das ist durchaus ein gängiges Verfahren, um bei wiederholten Abfragen schneller zu sein. Und genau das würde dein Phänomen erklären. Erste Abfrage relativ langsam und bei Wiederholung sehr schnell.
Bei wenig Puffer fliegen dann die Abfragen natürlich irgendwann wieder raus.

Ich hatte das bei einer meiner Anwendungen so gelöst, dass beim Programmstart die erste Abfrage in einem Thread druchgeführt wurde. Da ging es aber nur um ein paar Sekunden. Bei 50 Sekunden hättest du trotzdem noch ein Problem, denke ich.
Außerdem kommt meine Vermutung, dass du in Delphi durch die M-D-Konstellation tatsächlich alle Detail-Daten lädst, zum tragen. Bei 634k Datensätzen dauert das dann. Wenn du an der Stelle das Konzept umstellst und immer nur die Daten lädst, die du tatsächlich benötigst, sollte die Performance deutlich besser werden. Ein Ansatz könnte sein, dass du im OnDataChange des Masters die tatsächlichen Detail-Daten holst.

Danke, habe schon mal in der Mastertabelle die Filterung eingegrenzt.

Aber was meinst Du mit "in der OnDatachange"-Prozedur nur die tatsächlichen Detail-Daten holen? In der SQL der Detail-Tabelle ist die Verknüpfung

WHERE Nr =: Nr

Somit sollten automatisch nur die passenden Daten geholt werden. Zudem ist Datasource der Detail-Tabelle auf die Datasource-Komponente der Mastertabelle gesetzt.

In der Datenbank-Unit sind die Datenbanklen vorausgewählt verbunden, während alle Tabellen deaktiviert sind. Bei Programmstart werden alle zu den jeweiligen Datenbanken (Analysen, Aufträge, Adressen) gehörigen Datentabellen und Abfragen aktiviert. Das geht relativ fix. Detail: 15 ms, Master 94 ms.

Gunther Troost hat folgendes geschrieben :

Aber was meinst Du mit "in der OnDatachange"-Prozedur nur die tatsächlichen Detail-Daten holen? In der SQL der Detail-Tabelle ist die Verknüpfung WHERE Nr =: Nr Somit sollten automatisch nur die passenden Daten geholt werden. Zudem ist Datasource der Detail-Tabelle auf die Datasource-Komponente der Mastertabelle gesetzt.

Das sieht dann schon korrekt aus. Ich bin davon ausgegangen, dass du die Automatik von Delphi für Master-Detail verwendest. Also ignoriere meine entsprechenden Anmerkungen einfach.

Gunther Troost hat folgendes geschrieben :

In der Datenbank-Unit sind die Datenbanklen vorausgewählt verbunden, während alle Tabellen deaktiviert sind. Bei Programmstart werden alle zu den jeweiligen Datenbanken (Analysen, Aufträge, Adressen) gehörigen Datentabellen und Abfragen aktiviert. Das geht relativ fix. Detail: 15 ms, Master 94 ms.

Weiter oben schreibst du, dass das Öffnen 51 Sekunden dauert. Vielleicht fehlt da etwas Kontext, den du noch mitteilen musst.

Das ist ja mein Problem. Ich versuche es weitger einzugrenzen, an welcher Stelle das Problem auftritt. Eine Tabelle, die auch länger beim Laden dauerte, habe ich durch eine Berechnungsfunktion ersetzt. Da ging es um Konzentrationsabhängige Abweichungen vom wahren Wert. Das habe ich ünbber die realen Ergebnisse gemittelt. Dadurch war diese Tabelle obsolet geworden und dabei habe ich festgestellt, dass bei Vorfilterung schon ein gewisser Performancegewinn auftrat. Obwohl der letztendliche Filterc immer ein anderer war.

Die Startöffnungszeiten sind wohl deswegen so schnell, weil dort außer Öffnen nichts passiert. Ich versuche - wie geschrieben - die kritische Stelle einzugrenzen. Doch im Debugging-Modus tritt komischerweise das Problem nicht auf. Da öffnen sich die Tabellen immer schnell. Hat das vielleicht was damit zu tun, dass man ja viel langsamer debuggt, als im Programm nachher die Schritte ablaufen?


ANMERKUNG und AKTUALISIERUNG: Ich habe den Fehler gefunden. Es war die besagte Tabelle, die ich zwar nicht mehr benutzte, die aber noch aktiviert wurde. Ich habe die Tabelle komplett aus dem Programm rausgeschmissen und auch die dazugehörigen Befehle. Manchmal sollte man konsequenter sein. Jetzt funktioniert das Programm wieder einigermaßen schnell.

Inhalt gelöscht, da der Fehler gefunden wurde.