Zitat von bernhard_LA:

OK, 3 x hintereinander Pech gehabt

a) als der Kunde vor 14 Tagen anrief und diesen komischen "record open" Fehler berichtet hat; leider keine Fehler beim Kunden oder in seinen Daten

Hä?

Zitat von bernhard_LA:

b) als der nächste Verdächtige (unser DB Admin) sich in erfolgreich aus der Schlinge befreien konnte (Meeting Dauer < 30 min )

Er hat sich nicht aus der Schlinge befreit. Für den Programmierfehler (bzw. eine für die Datenmenge ungeeignete Heransgehensweise) kann der DB-Admin nix.

Zitat von bernhard_LA:

c) sich hier im Forum keine gefunden hat der uns eine Lösung für 12 Mio Datensätze in einer Query oder sonstwo gezeigt hat oder zeigen wollte.

Haben wir doch. Ich selbst habe dir 2 Lösungsmöglichkeiten aufgezeigt.

Zitat von bernhard_LA:

Also haben wir in den letzten beiden Tagen (heimlich) unseren Code inspiziert und

Wer wir? Ihre als Mitarbeiter der Firma dürft euren Quellcode nur heimlich inspizieren? Was ist das für eine Firma? Oder verstehe ich dich jetzt falsch?

Zitat von bernhard_LA:

a) Stellen gefunden an denen das Problem simple umgangen werden kann ("hätte man schon längst machen sollen...")

Was jetzt? Du kannst das Problem erst mal kurzfristig Lösen ohne das der Kunde Tausende € in die Hand nehmen muss um die Rechner auf 32 oder 64 GB aufzurüsten?
Dann mach es und sag deinem Chef das hier zwingend Zeit investiert werden muss um eine vernünftige Lösung auszusuchen (gefunden haben wir sie ja schon) und sie gut zu integrieren.

Zitat von bernhard_LA:

c) es gibt noch Stellen wo wir aktuell keine "universelle Lösung" sehen ("wenn es leicht wäre könnte es ja jeder machen ....")

Was ist eine Universelle Lösung? Es gibt welche (wurden auch schon genannt)

Zitat von bernhard_LA:

Unangenehm weil heute zeitlich nicht eingeplant und nicht Abschätzbar im Aufwand

Probleme sind eigentlich fast nie Zeitlich eingeplant. Aber wenn Sie da sind muss man sie mit entsprechender Priorität angehen.
Und da ist ein "heimliches" Inspizieren nicht zielgerichtet sondern da muss einen der Chef entsprechend Zeit geben um das zu Lösen. Oder ist hier der Kunde für eure Firma nur störend?

Zitat von Bernhard Geyer:

Zitat von bernhard_LA:

c) sich hier im Forum keine gefunden hat der uns eine Lösung für 12 Mio Datensätze in einer Query oder sonstwo gezeigt hat oder zeigen wollte.

Haben wir doch. Ich selbst habe dir 2 Lösungsmöglichkeiten aufgezeigt.

Zitat von bernhard_LA:

c) es gibt noch Stellen wo wir aktuell keine "universelle Lösung" sehen ("wenn es leicht wäre könnte es ja jeder machen ....")

Was ist eine Universelle Lösung? Es gibt welche (wurden auch schon genannt)

Die universelle Lösung heißt 'Paging'. Dazu musst Du
1. Eine View mit mit Schemabindung erzeugen. Bei SQL < 2005 zusätzlich noch einen PRimary key
2. Indexe auf die zu filternden Spalten legen
3. nach 'Paging' googeln
4. die Kleinigkeit nur noch umsetzen (z.B. als VirtualList<IDataRow> )

Wenn Du das Pattern 'Zeige verdammt viele Daten im Grid' hast, dann musst Du
a) ein virtual Dataset besorgen (kaufen oder selbst schreiben)
b) eine Komponente besorgen, die virtuelle Daten anzeigen kann
c) die Virtual TreeView einsetzen

Bei (b) würde ich dir zu DevExpress raten.

Beim Pattern 'eigentlich müssen wir die gar nicht sehen, aber verarbeiten schon' reicht die virtuelle Liste.

DAS SIND UNIVERSELLE LÖSUNGEN FÜR DAS PROBLEM. Wie oft denn noch?

Ich vermute, Du hast keine Ahnung, wie cool Paging ist. Ich sag Dir mal was: Wenn Du in deiner Tabelle 100 Trillionen Datensätze hast, und willst Die jetzt mal alle anzeigen (bzw. durchscrollen), dann hängt sich deine Methode auf. Zwangsweise. 'Meine' Methode dagegen benötigt ca. 0.1s, um die Daten anzuzeigen. Dann kannst Du auf 'Page Down' drücken, die Taste mit einem Streichholz oder Tesa festbeppseln, und dir den echt spannenden Film '100 Trillionen Zeilen rasen über den Bildschirm' anschauen. Ohne jegliche Verzögerung.

So, nun klink ich mich hier aber kopfschüttelnd aus.

@Dejan Vu:

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.