Ich befürchte aber, dass das Problem nicht nur an der Datenanbindung allein liegt. Da er die Daten ja nach dem Einlesen in eine Objektliste packt, ist es ja egal, ob das Einlesen nun in einem Rutsch oder in kleineren Paketen erfolgt. Da man aber den genauen Code nicht kennt ( er postet ja immer Testcode, der vielleicht zufällig den gleichen Fehler erzeugt oder Codesegmente, welche viele anderen Prozeduren aufruft (blackbox). Die Prozeduren sind auch noch ohne Parameter!
Das Programm sollte man grundsätzlich auf den Prüfstand stellen und dann teilweise/komplett neu Schreiben!

Zitat von mkinzler:

Ich befürchte aber, dass das Problem nicht nur an der Datenanbindung allein liegt. Da er die Daten ja nach dem Einlesen in eine Objektliste packt, ist es ja egal, ob das Einlesen nun in einem Rutsch oder in kleineren Paketen erfolgt.

Entsprechend dem 5ten Post (http://www.delphipraxis.net/1261946-post5.html) reicht es schon die Mio-Datensätze im Client anzufordern (CurserLocation = clUseClient)

Zitat von mkinzler:

Das Programm sollte man grundsätzlich auf den Prüfstand stellen und dann teilweise/komplett neu Schreiben!

Aber nur geheim - Chef darf ja nix davon erfahren das im Quellcode noch ein paar Supportechnische Bomben versteckt sind ...

Zitat:

Zitat von mkinzler:
Ich befürchte aber, dass das Problem nicht nur an der Datenanbindung allein liegt. Da er die Daten ja nach dem Einlesen in eine Objektliste packt, ist es ja egal, ob das Einlesen nun in einem Rutsch oder in kleineren Paketen erfolgt.
Entsprechend dem 5ten Post (MSSQL/ADO + 3 Mio Datensätze , Thread Error) reicht es schon die Mio-Datensätze im Client anzufordern (CurserLocation = clUseClient)

Ich hätte vielleicht nicht nur und allein unterstreichen sollen
In seinem Testprogramm hat er das DataSet ja auch noch in einem Grid anzeigen lassen, dann hat er die 3 Mio Datensätze ja noch öfters im Speicher.
Tipps für den TE (oder jemand anderes der ähnliches vor hat oder macht und für Vorschläge offen ist [bzw. dessen Chef...]):
-Nur Daten Lesen, die benötigt werden
-Ist eine Speicherung in Objektliste notwendig ( kann ja sein)?
-Manipulation der Daten direkt in der Datenbank
-Nur zur Anzeige kein komplettes laden der daten notwendig (paging, "virtuelle" Anzeigekomponenten, ...)
-Überprüfung Datenbankstruktur ( Verwendung von T<xx>Table oft in Verbindung mit Abwesenheit von Normalisierung).
-...

Zitat von mkinzler:

Ich hätte vielleicht nicht nur und allein unterstreichen sollen
In seinem Testprogramm hat er das DataSet ja auch noch in einem Grid anzeigen lassen, dann hat er die 3 Mio Datensätze ja noch öfters im Speicher.

Bei einem DB-Grid - Nein. Da wird die gerade Angezeigten Datensätze direkt aus dem Dataset geholt und visualisiert. Aber es erfolgt keine doppelte Speicherung.

Für die angezeigten schon

Zitat von mkinzler:

Für die angezeigten schon

Evtl. 50 von einigen hunderttausend/millionen - Ob das den Kohl fett macht?

Zitat von mkinzler:

Für die angezeigten schon

Wie oft lese ich das denn noch? Der Thread-Autor möchte die Daten nicht anzeigen, weder in einem Grid noch in einer Liste.

Er möchte nur die x Mio DS lesen und in Objekte umwandeln und dann auf den Objekten arbeiten. Wäre damit gut, die Anzeigediskussion zu beenden und den Autor mal wieder kommen zulassen: mit realen Codebeispielen und besser formulierten Fragen.

Ein wenig Hintergrund über seinen Delphihintergrund würde der Diskussion auch helfen.

Christoph

Zitat von pertzschc:

Wie oft lese ich das denn noch? Der Thread-Autor möchte die Daten nicht anzeigen, weder in einem Grid noch in einer Liste.

Es kracht aber schon beim öffnen der Table-Komponenten an der zufälligerweis auch ein grid hängt.
Es wüde auch ohne Grid krachen.

Zitat von pertzschc:

Er möchte nur die x Mio DS lesen und in Objekte umwandeln und dann auf den Objekten arbeiten.

Wenn seine Objekt weniger Speicher als die ADO-Recordsets haben dann habe ich ihm schon einen einfachen Tipp gegeben: Forward-Only-Curser

Zitat von pertzschc:

Wäre damit gut, die Anzeigediskussion zu beenden und den Autor mal wieder kommen zulassen: mit realen Codebeispielen und besser formulierten Fragen.

Anzeigen oder nicht ist egal. 3 Mio-Datensätze die "etwas breiter" sind werden mit ADO/dbGo-Overhead zu viel Speicher benötigen das es schon kracht.

Aber wenn wirklich auch das Testprogramm 64-Bittig ist sollte der Speicher doch kein Problem darstellen (auch wenn es besch**** implementiert ist bei der Anzahl der Datensätze).
Was würde passieren wenn man direkt ohne dbGo nur mit ADO-Mitteln die Daten abholen würde?

Kann man die Daten nicht einfach häppchenweise lesen?

Er kann sich die Summe holen und teilt das durch ne annehmbare Zahl und liest entweder parallel, was natürlich dann auch so viele Connections bedeutet oder einfach X mal 10.000 Datensätze und verschiebt seinen Cursor einfach weiter nach oben.

Zitat von -=ZGD=-:

Kann man die Daten nicht einfach häppchenweise lesen?

Er kann sich die Summe holen und teilt das durch ne annehmbare Zahl und liest entweder parallel, was natürlich dann auch so viele Connections bedeutet oder einfach X mal 10.000 Datensätze und verschiebt seinen Cursor einfach weiter nach oben.

Wenn man wüßte was er wirklich treibt, könnte er auch ein paar konkrete Lösungsvorschläge bekommen.

Zitat:

4. Dateivolumen 800 Mbyte
5. Index Volumen 200 Mbyte
6. Anzahl der Datensätze in der Größten Tabelle ~ 3 Mio

Da ist jeder Datensatz ca. 255 Byte groß (wenn der Rest neben der ominösen Tabelle so gut wie keinen Inhalt hat) Das sollte auch mit 32Bit-Programmen zu handhaben sein.

Dann taucht der Fehler bein "Einfügen" auf, dann wiederum beim Einlesen "bevor die Daten ins Grid kommen"

Alles etwas konfus.

Gruß
K-H