Abfrage von großen Datenmengen

[dARKeAGLE]

Hallo Zusammen,

sobald ich eine Abfrage starte, welche mehr als ca. 20 000 Datensätze zurückliefert läuft mein Arbeitsspeicher voll und die Exception "Nicht genügend Speicher für diese Operation" wird ausgegeben.

Des Weiteren habe ich noch eine Master/Detail-Beziehung

Der Master (Mandant) hat 8 Datensätze, je nach Master gibt es unterschiedliche Buchungen(Detail).

Code:

+-----------+-------------------+
| Mandant    |  Anzahl Buchungen |
+-----------+-------------------+
|!01        |  11000            |
|!02        |  30000            |
|!03        |  40000            |
|!04        |  523624           |
|!05        |  10000            |
|!06        |  10000            |
|!5         |  10000            |
+-----------+-------------------+

Sobald ich die innerhalb des Masters scrolle, ändert sich ja auch der Details (was gewünscht ist), doch bei einer größeren Anzahl kommt die obengenannte exeception.

Hat jemand eventuell eine Idee wie das Problem gelöst werden kann.


Viele Grüße und vielen Dank im Voraus

Christian


P.S.: Das Projekt sowie ein Backup der MySQL-Daten sind angehängt

[Bernhard Geyer]

20.000 Datensätze. Hier die Frage wieder: Wer schaut sich dies direkt an?

Mit welchen Compilereinstellungen ist die Anwendung erstellt? Mit maximalen Debug-Infos?

[dARKeAGLE]

Also 20.000 Datensätze ist noch das kleinste, aber wer des anschauen will keine Ahnung. Ist glaub für ein komplettes Geschäftsjahr.

Ja die Anwendung wurde mit den maximalen Debug-Infos kompiliert. Auch den Debug-DCUs.

Muss ich es irgendwie anders kompilieren?

Viele Grüße

Christian

[p80286]

zum einen, wäre es nicht sinnvoller gleich eine Datei als Ausgabe zu generieren? (Excel)
Ohne Debug-Info ist die Exe etwas kleiner und man etwas mehr Platz.

Ggf. wäre es sinnvoll einen readonly-cursor zu verwenden (falls definierbar) oder den Cursor auf dem Server zu verwenden (falls es geht)

Gruß
K-H

[stahli]

Verwendest Du ClientDataSets?
Dann werden alle Abfragedaten darin (im Speicher) verwaltet.
Insofern eignet sich DBExpress nicht unbedingt für solche größeren Rückgabemengen von Abfragen.

(soweit meine Einschätzung als DB-Laie)

[dARKeAGLE]

Jein. Ich nutze zwei TSimpleDataSet und eine TSQLConnection mit dem Devart Treiber MySQL Direct. Das TSimpleDataSet erbt ja vom TCustomClientDataSet.

Gibt es keine Komponenten für Read-Only zugriffe, da ich die Daten NUR lesen will und nicht wieder wo anderes hin speichere oder manupuliere möchte.

Zitat von p80286:

zum einen, wäre es nicht sinnvoller gleich eine Datei als Ausgabe zu generieren? (Excel)
Ohne Debug-Info ist die Exe etwas kleiner und man etwas mehr Platz.

Ggf. wäre es sinnvoll einen readonly-cursor zu verwenden (falls definierbar) oder den Cursor auf dem Server zu verwenden (falls es geht)

Gruß
K-H

Also ohne die Debug-Informationen bekomme ich leider auch nicht mehr Datensätze über die Leitung.

Grüße

[p80286]

Zitat von dARKeAGLE:

Jein. Ich nutze zwei TSimpleDataSet und eine TSQLConnection mit dem Devart Treiber MySQL Direct.

Du nutzt also keine query um nur die gewünschten Daten von der DB zu holen?

Gruß
K-H

[Uwe Raabe]

Zitat von dARKeAGLE:

Jein. Ich nutze zwei TSimpleDataSet und eine TSQLConnection mit dem Devart Treiber MySQL Direct. Das TSimpleDataSet erbt ja vom TCustomClientDataSet.

Das Problem ist das TSimpleDataSet. Das ist, wie du schon bemerkt hast, ein TCustomClientDataSet. Somit hat es auch genau dieselben Einschränkungen. Es erspart dir lediglich ein SQLDataSet und einen DataSetProvider, die du andernfalls selbst verdrahten müsstest.

Das Simple-/ClientDataSet lädt stndardmäßig das komplette Abfrageergebnis in den Hauptspeicher und da knallt es natürlich ab einer gewissen Menge.

Du kannst also entweder deine Abfrage mit einer sinnvollen WHERE-Klausel verkleinern, was aber ohne Kenntnis möglicher Kriterien schwierig wird, oder (besser) du verzichtest auf das Grid und verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar). Da sich aber wohl kaum jemand die ganzen 20000 Datensätze in dem Grid anschauen will, sollte das zu verschmerzen sein.

Wenn es nicht ohne das Grid geht, musst du feststellen, nach welchen Kriterien die Abfrage eingeschränkt werden kann (z.B. Jahr/Monat der Buchungen oder so). Dann zuerst das Kriterium eingeben und dann erst die Abfrage öffnen.

Vergiss alles bezüglich der Debug-Infos, das Problem ist die Menge der abgefragten Daten.

[Bernhard Geyer]

Zitat von dARKeAGLE:

Ja die Anwendung wurde mit den maximalen Debug-Infos kompiliert. Auch den Debug-DCUs.

Muss ich es irgendwie anders kompilieren?

Probiers mal ohne jegliche Debug-Infos. Diese blähen Teilweise den benötigen Speicherbedarf aufs 5-10fache auf.

[dARKeAGLE]

Zitat von Bernhard Geyer:

Zitat von dARKeAGLE:

Ja die Anwendung wurde mit den maximalen Debug-Infos kompiliert. Auch den Debug-DCUs.

Muss ich es irgendwie anders kompilieren?

Probiers mal ohne jegliche Debug-Infos. Diese blähen Teilweise den benötigen Speicherbedarf aufs 5-10fache auf.

Habe es gerade ausprobiert, im Anhang meine Einstellungen.
Leider waren es nur ca. 30MB, was reduziert wurde. Aber bei 1,7 GB ist das nur ein Tropfen auf den heißen Stein.

Grüße