Abfrage von großen Datenmengen

[dARKeAGLE]

Sorry habe mich beim Backup vertan. Daher im Anhang nun das Backup der Tabelle "Mandant".


Man beachte es nur Test-Daten die ich mir erzeugt habe. Daher steht nichts sinnvollen in den Datensätzen

[dARKeAGLE]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1197478)

Zitat:

Zitat von dARKeAGLE (Beitrag 1197466)

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

[Bernhard Geyer]

Schon mal andere MySQL-Version probiert?
Hatte schon den Fall das eine MySQL-Version verpfuscht war und falsche infos zurück geliefert hatte so das auf Clientseite einiges Falsch gelaufen ist

Hast du blob-Felder?
Bei Oracle war/ist es so das diese (auch ohne Inhalt) im Instant-Client mit sehr viel "luft" (Speichertechnisch) auf Clientseite verwaltet werden.

Verwendest du libmysql.dll oder den direkten Modus der Komponenten?
Probier mal den jeweilig anderen Modus aus.

[Morphie]

Also ich kann das Problem hier jetzt nachvollziehen... Spontan würde ich sagen es liegt an den (komischen) dbExpress-Zugriffskomponenten...

Habt ihr die schon gekauft, oder seid ihr noch am testen?
Ich rate dir, die Zugriffskomponenten zu wechseln und auf TQuery zu setzen.

http://www.devart.com/mydac/ordering.html
Kostet ja im Prinzip in der kleinsten Ausbaustufe genau so viel. Damit wirst du wohl viel weniger Probleme haben...

[Uwe Raabe]

Zitat:

Zitat von dARKeAGLE (Beitrag 1197471)

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.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1197484)

...verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar).

Warum sollte man es nicht in einem TStringgrid darstellen können?

Gruß
K-H

[Morphie]

Ihm geht dabei aber dann doch die Master / Detail Navigation flöten, oder?
Das Problem hätte er wie gesagt mit den gleichteuren MyDAC-Komponenten von DevArt nicht...

[stahli]

(Bezugnahme auf Uwe´s Beitrag)
... oder eine Alternative zum DBExpress wählen.

Ich kenne mich im Detail zwar nicht aus und WILL NICHT die BDE empfehlen, aber unter BDE wurden nur die Datensätze in das DBGrid geholt, die auch dargestellt wurden.

Ich weiß nicht, welche Möglichkeiten sich da aktuell anbieten.

Bei DBExpress zu bleiben ist m.E. vor allem sinnvoll, wenn man eine spätere Skalierung auf DataSnap für möglich hält. So ließe sich das Projekt (m.E.) am einfachsten auf DataSnap umstellen.
Ist das ausgeschlossen und sind große bidirektionale Datenmengen im Spiel ist BDExpress möglichweise nicht erste Wahl.

(meine aktuelle Einschätzung)

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1197484)

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

Bei MySQL ist das egal da es hier keine serverseitigen Curser gibt.

Zitat:

Zitat von Uwe Raabe (Beitrag 1197484)

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

20.000 Datensätze sollten aber (wenn keine größeren Blobs) beteiligt sind selbst in einem 32-Bit Prozess noch keine Probleme darstellen.

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1197488)

Ich kenne mich im Detail zwar nicht aus und WILL NICHT die BDE empfehlen, aber unter BDE wurden nur die Datensätze in das DBGrid geholt, die auch dargestellt wurden.

Nützt dir aber nur was wenn die Datenbank Serverseitige Curser unterstützt. Und das gibt es bei MySQL nicht. Die DevArt-Kompos können zwar sowas simulieren indem einfach die Datensätze nicht abgeholt werden, führt aber AFAIk dazu das hierfür eine eigenen Connection aufgebaut wird.