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:

Zitat von p80286 (Beitrag 1197469)

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:

Zitat von dARKeAGLE (Beitrag 1197471)

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

[dARKeAGLE]

Wenn du als Query eine TSQLQuery meinst, dann nicht.

Sorry dass ich gerade nicht verstehe was du meinst. :)

[Morphie]

Ich wollte mir dein Projekt mal ansehen, aber ich glaube dein MySQL Backup ist nicht vollständig, kann das sein?
In der Datei stehen nur zwei Tabellen: Buchungen und email

Im Quellcode verweist du aber auf die Tabelle Mandant?!

[Bernhard Geyer]

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.

[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.

[stahli]

Ich kann mir das Projekt gerade nicht ansehen, aber vielleicht gibt es ein Memoryleak o.ä. (dass z.B. dynamisch immer neue Verbindungen hinzugefügt werden oder so)?

EDIT @Christian:
Bist Du auf MySQL festgelegt? Sonst teste doch mal Firebird...

[Sir Rufo]

Diese redundaten (Adress-) Daten in der Buchungen Tabelle sind ja nun auch nicht wirklich hilfreich und haben in der Tabelle "buchungen" eigentlich nichts verloren.

Die Adressinformationen gehören in eine Belegtabelle und die Referenz auf den Beleg gehört in die Buchungstabelle.

Ich würde hier einfach mal ordentlich normalisieren und dann wieder zu diesem Problem zurückkommen - wahrscheinlich hat sich dieses Problem dann schon erledigt.

Alle Spalten als varchar(500) ist auch nicht gerade kreativ ...

[Sir Rufo]

da kommt mir doch ein Gedanke wegen der Größe ...

73 Felder mit VARCHAR(500)

Wenn die Datenbankkomponente jetzt die Felder in maximaler Größe und als Unicode in den Speicher holt dann sind das bei 20000 Zeilen:

Code:

73 {Felder} * 500 {CHAR} * 2 {Unicode} * 20000 {Zeilen} = 1460000000 Bytes
1,360GB

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1197485)

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?

Gemeint war natürlich ein TDBGrid! Das kann mit unidirektionalen DataSets nichts anfangen.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1197489)

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.

Das hat damit nichts zu tun. Das ClientDataSet schickt eine Anfrage an den DataSetProvider, der diese wiederum an das SQLDataSet weitergibt. Dieses liefert eine Ergebnismenge, die der DataSetProvider an das ClientDataSet weitergibt. Intern wird dabei das MyBase-Format (Midas) zum Transport verwendet, bei dem die gesamte Datenmenge im Hauptspeicher vorliegt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1197489)

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

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1197496)

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

Das wollte ich auch schon ausrechnen.
Seine Testdaten zeigen aber keine annähernde füllung dieser jeweils 500 Byte (Backup ist insgesamt ca. 500 MB groß) so das ich denke das diese 20.000 Datensätze kein 1,5 GB (wenn keine Fehler vorhanden sind) füllen würden.

[p80286]

Es soll ja auch schon vorgekommen sein das varchar500 als 500 Blanks über die Leitung gehen, intern aber wirklich nur ein Blank groß sind.

Vielleicht hilft da der Debugger weiter?

Gruß
K-H

[stahli]

Es kann natürlich sein, dass die Datenbank (File) leere Einträge packt, der Treiber die DataSet-VarChar-Felder aber immer mit Leerzeichen auffüllt bzw. einfach maximal viel Speicherplatz reserviert.

[dARKeAGLE]

Zitat:

Zitat von stahli (Beitrag 1197491)

Ich kann mir das Projekt gerade nicht ansehen, aber vielleicht gibt es ein Memoryleak o.ä. (dass z.B. dynamisch immer neue Verbindungen hinzugefügt werden oder so)?

EDIT @Christian:
Bist Du auf MySQL festgelegt? Sonst teste doch mal Firebird...

Nein auf MySQL bin ich nicht festgelegt. Habe auch die Treiber für Oracle und MSSQL.
Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Zitat:

Zitat von Sir Rufo (Beitrag 1197494)

da kommt mir doch ein Gedanke wegen der Größe ...
73 Felder mit VARCHAR(500)

Wenn die Datenbankkomponente jetzt die Felder in maximaler Größe und als Unicode in den Speicher holt dann sind das bei 20000 Zeilen:

Code:

73 {Felder} * 500 {CHAR} * 2 {Unicode} * 20000 {Zeilen} = 1460000000 Bytes
1,360GB

Die Größe der Felder mit VARCHAR(500) wurde frei gewählt, und ich sehe es nun auch ein, dass es totaler Blödsinn war.:(:(
Ich hoffe, man möge es mir verzeihen.

Zitat:

Zitat von Sir Rufo (Beitrag 1197493)

Diese redundaten (Adress-) Daten in der Buchungen Tabelle sind ja nun auch nicht wirklich hilfreich und haben in der Tabelle "buchungen" eigentlich nichts verloren.

Die Adressinformationen gehören in eine Belegtabelle und die Referenz auf den Beleg gehört in die Buchungstabelle.

Ich würde hier einfach mal ordentlich normalisieren und dann wieder zu diesem Problem zurückkommen - wahrscheinlich hat sich dieses Problem dann schon erledigt.

Alle Spalten als varchar(500) ist auch nicht gerade kreativ ...

Natürlich sollen die Daten nichts representieren, sondern nur für die Fülle von Daten stehen.



Gibt es bei einer TSQLQuery die Möglichkeit eine Master-Detail-Beziehung aufzubauen (Kann es leider nicht nachprüfen, da ich nur im Unternehmen eine Delphi-Version habe)?

Das mit dem Debugger werde ich gleich mal morgen ausprobieren.

Viele Grüße

[p80286]

Zitat:

Zitat von dARKeAGLE (Beitrag 1197508)

Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Da kann die Datenbank eigentlich nichts für.

vielleicht solltest Du mal ganz von Anfang an erzählen, um was es geht. Mir scheint hier wird nur an den Symptomen herum gemacht.
(nicht pers. gemeint)

Gruß
K-H

[dARKeAGLE]

Ist OK. Also es war einmal .... ne nur Spaß.


Es gibt zwei Anwendungen. Die Eine, ein ERP-System (Java), bereitet Daten für ein Report-Template auf. Anschließend wird die zweite Anwendung gestartet. Diese Anwendung ladet die Daten und erstellt ein PDF aus den Daten mit Hilfe des Templates. Aktuelle gibt es ca. 90 verschiedene Templates mit ca. 40 verschiedenen SQL-Abfragen. Von diesen Abfragen werden je nach Template 2-3 Abfragen benötigt. Ja, manche Templates haben das selbe Abfrage.


Da das Laden der SQL-Abfrage und das Zusammenbauen der Master-Detail-Beziehungen dynamisch geschieht, sollte es halt eine einheitliche Lösung sein.


Nun zum Problem:

Aktuell soll ein Report generiert werden, welcher im Detail ca. 250 000 Datensätze besitzt. Hierbei kommt es zur der Exception, dass nicht genügend Speicher vorhanden ist, also die Exception auf dem dieser Thread basiert. Die Datenbank an dem der Fehler auftrat war Oracle. Da ich den Fehler "schnell" reproduzieren wollte, habe ich kurzer Hand ein paar Testdaten geniert. Dadurch auch die Problematik mit Felder VARCHAR(500). Sollte quick'n'dirty sein.

Die Anzahl der Spalten im Produktivsystem liegen so bei 50 Stück mit unterschiedlichen Datentyp.


Da ich den Reportbuilder von Digital Methaphors verwende benötige ich ein Dataset (siehe http://www.digital-metaphors.com:8080/Data_Access).


Vielleicht gibt es auch eine andere Lösung, solange es meine Master-Detail-Beziehung nicht gefährdet.

Hoffe ich habe alles erklärt und auch verständliche erklärt.
Falls noch einige Einzelheiten fehlen werde ich diese gerne nachreichen.


Vielen Dank im Voraus.

Viele Grüße

Christian

[jobo]

Ohne ins Detail zu gehen. In einem Client Server System dient der Server zur Aufbereitung der Daten, der CLient zur Pflege und Darstellung.
250000 Detaildatensätze schaut sich niemand an. Naheliegend, dass sie mit dem Reportsystem das Du verlinkt hast irgendwie weiterverarbeitet werden (sprich eingedampft). Da es um Reporting geht, scheidet eine einfache Beschränkung der Datensatzanzah aus. Ich kenn das jetzt nicht konkret, aber Du kannst die Hersteller ja mal anmailen, wie ihre Reportkomponenten mit Datenmengen > 100000 Records umgehen...

Wenn Du das ganze Verfahren nicht ändern kannst, empfehle ich einen genaueren Blick auf die Detaildaten. Vielleicht kann man hier mit Teilaggregationen arbeiten, Spalten weglassen usw. und so irgendwie auf Datenmengen kommen, die clientseitig verarbeitet werden können.

[Uwe Raabe]

Zitat:

Zitat von dARKeAGLE (Beitrag 1197521)

Da ich den Reportbuilder von Digital Methaphors verwende benötige ich ein Dataset (siehe http://www.digital-metaphors.com:8080/Data_Access).

Die Aufgabe sollte mit zwei SQLDataSet, die über eine DataSource in eine Master-Detail-Beziehung gebracht werden, zu lösen sein.

[dARKeAGLE]

Zitat:

Zitat von jobo (Beitrag 1197529)

Ohne ins Detail zu gehen. In einem Client Server System dient der Server zur Aufbereitung der Daten, der CLient zur Pflege und Darstellung.
250000 Detaildatensätze schaut sich niemand an. Naheliegend, dass sie mit dem Reportsystem das Du verlinkt hast irgendwie weiterverarbeitet werden (sprich eingedampft). Da es um Reporting geht, scheidet eine einfache Beschränkung der Datensatzanzah aus. Ich kenn das jetzt nicht konkret, aber Du kannst die Hersteller ja mal anmailen, wie ihre Reportkomponenten mit Datenmengen > 100000 Records umgehen...

Wenn Du das ganze Verfahren nicht ändern kannst, empfehle ich einen genaueren Blick auf die Detaildaten. Vielleicht kann man hier mit Teilaggregationen arbeiten, Spalten weglassen usw. und so irgendwie auf Datenmengen kommen, die clientseitig verarbeitet werden können.

Der Sinn hinter diesen großen Datenmengen erschließt sich mir auch nicht. Leider habe ich keinen Einfluss auf die Daten und muss mit den vorhandenen Arbeiten.

Ich glaube, dass mit den TSQLDataSet funktioniert auch nicht, da Sie unidirektional sind, aber der Reportbuilder bi-direktionale DataSet benötigt.

Zitat:

The reports and datapipelines use dataset bookmarking. Make sure the dataset can support bi-directional navigation.

Siehe hier:
http://www.digital-metaphors.com:808..._Access_Errors

Vielleicht habe ich es auch falsch verstanden.
Gibt es sonst noch eine Möglichkeit, das Caching von ClientDataSets in eine Datei auszulagern?

Viele Grüße

Christian

[Furtbichler]

Ich weiß, das Nachbohren nervt: Werden wirklich 250.000 Datensätze im Report dargestellt und muss das so sein? "Äh, die wollen das so" ist zunächst keine Antwort. Man kann ja auch mal anmerken, das es Probleme bereitet.

Wenn JA (weil z.B. Niemand nachdenken will, warum, und Du den Rotz ausbaden musst), dann geht es ja eigentlich nur um den Auftrag, diesen Mumpitz zu produzieren. Hier sollte man sich überlegen, ob man nicht anderweitig, also ohne diesen Reportbuilder, zum Ziel kommt. Das geht z.B. über Exportfunktionen des RDBMS: Die Daten werden also vom DB-Server direkt in eine Datei geschrieben (z.B. EXCEL). Dann muss sich der Endanwender eben rumschlagen, wie er die 250k-Zeilen-Datei in seinen Rechner bekommt.

Andererseits kenne ich keinen Reportbuilder (und auch keinen Anwendungsfall), bei dem man durch diese Datenmassen scrollen muss. Die Vorgabe, beliebig viele Daten anzeigen zu können, ergibt sich meistens aus der Tatsache, das die Anwendung bestimmte Funktionen nicht bietet, die Anwender jedoch bestimmte Probleme lösen müssen.

Ich habe gerade konkret solche Fälle, bei denen es um die Massenkorrektur von Daten geht.
Die Daten müssen auf Eingabefehler oder Inkonsistenzen geprüft werden. Das kann die Anwendung nicht, also haben sich die Sachbearbeiter den Trick ausgedacht: Daten laden, als XLS-exportieren, in EXCEL öffnen und filtern/sortieren, um Probleme zu erkennen, dort korrigieren und als CSV speichern. Dann wird aus der CSV-Datei über RegEx eine Datei mit 100.000 UPDATE-Befehlen erstellt, die dann zum DB-Server geschickt wird. Toll, gell?

Das Problem ist also hier z.B. das Fehlen einer direkten Exportfunktion, ohne Umweg über das Grid oder gleich das Richtige Datenvalidierungs- und korrekturtool.

Deshalb ist es so immens wichtig, den genauen Grund zu erfahren, wieso irgendwo 250k Datensätze aufgelistet werden müssen. Na, und wenn darauf bestanden wird, durch 250k Datensätze zu scrollen, dann baut man eben einen Pagingmechanismus, das sollte doch wohl gehen.

[dARKeAGLE]

Hallo,

nachbohren nervt nicht, ist manchmal auch sehr wichtig.:)


Ich habe mir mal die Daten, genau angeschaut. Im Master steht ein Datensatz, welcher nur Überschriften enthält. Im Detail sieht es noch schlimmer aus. Hier werden alle Datensätze kombiniert zusammengefasst. Dies bedeutet die 250 000 Datensätze setzen sie z.B. wie folgt zusammen:

250 000 Buchungen = (Mandant A * 200 Buchungen) + (Mandant B * 300 Buchungen) + (Mandant C * 300 Buchungen) + ... + ...

Aufgrund dessen habe ich mal genauer nachgefragt, wie man so eine Datenhaltung rechtfertigt :)
Die Antwort:
Ist das es mehrere Ausgaben (Listen, Tabellenkalkulation und noch 5 weitere) im System gibt und daher die Daten so abgelegt werden. Der Reportbuilder soll nur die ERP-Software im neuen Jahrtausend willkommen heißen, damit die Auswertungen gleich an die Mandanten in schöner Form geschickt werden können, also als Brief oder Email.
Gerade mit den 250 000 Datensätzen wären das ca. 3-15 Seiten pro Mandant, die geniert werden sollen. Was ja wieder human ist und sich auch jemand durchliest.

Dennoch wird die Master-Detail-Beziehung benötigt, weil es andere Reports gibt, die wirklich nicht nur einen Master-Datensätz haben, sondern das Prinzip der Master-Detail-Beziehungen folgen.

Im Moment könnte ich nur :kotz:, weil ich seit 5 Tagen nichts anderes mache. Und keinen Millimeter voran komme.

Viele Grüße

[Morphie]

Dann frag ich auch noch mal nach, warum du nicht die MyDAC-Komponenten von DevArt nimmst? damit ist es ein Kinderspiel und es gibt auch keine Fehler. (gerade mit deinem Projekt getestet)

MyConnection1:
Username, Password, Server, Port und Database eintragen
LoginPrompt = false
Connected = true

MyQuery1:
SQL = SELECT * FROM MANDANT;
Connection = MyConnection1
Active = true

MyDataSource1:
Dataset = MyQuery1

dbgrdMaster:
DataSource = MyDataSource1

MyQuery2:
SQL = SELECT * FROM BUCHUNGEN;
MasterSource = MyDataSource1
MasterFields = Mandant
DetailFields = Mandant
Connection = MyConnection1
Active = true

MyDataSource2:
DataSet = MyQuery2

dbgrdDetail:
DataSource = MyDataSource2

[dARKeAGLE]

Sieht ja nicht schlecht aus.

Bin schon seit gestern am überlegen. Haben halt erst vor 4 Monaten die gesamten DBExpress Treiber für MySQL, Oracle und SQL Server gekauft, daher wird mein Chef nicht unbedingt erfreut sein, wenn ich schon wieder was will. Aber das ist ein anderes Problem.

Daher meine Frage:

Reicht auch der Universal Data Access Components oder ist es besser wieder für jede Datenbank es einzelt zu kaufen? Oder soll ich für die Frage einen neuen Thread stellen?

Viele Grüße

Christian

[Morphie]

Sollte eigentlich mit denen auch funktionieren... Man kann sich aber auch Trial-Versionen herunterladen und testen... Das würde ich mal vorschlagen ;-)

[dARKeAGLE]

Zitat:

Zitat von Morphie (Beitrag 1197583)

Sollte eigentlich mit denen auch funktionieren... Man kann sich aber auch Trial-Versionen herunterladen und testen... Das würde ich mal vorschlagen ;-)

Habe mir mal das Universal Gedöhns geladen. Es funktioniert sogar mit der kaputten Datenhaltung (VARCHAR(500)) und 500 000 Datensätzen (Mandant "!04") kommt er nicht mal über 1GB Ram Auslastung :) so kann ich des mein Chef gut verkaufen.

Viele Dank nochmal an alle die mir geholfen haben.

Viele Grüße

Christian