Und das "machwas" auf die DB zu verschieben geht nicht?

Gruß
K-H

Zitat von bernhard_LA:

Eurer Idee habe ich schon verstanden , nur führt die leider nicht zum Ziel.

Wirklich? Bezweifle ich.

Zitat von bernhard_LA:

Meine Anwendung ist ganz gut vergleichbar mit einem CAD Programm, wenn der Anwender auf den "Male Gegenstand auf Bildschirm, z.b. einen Pkw "
Button drückt dann läuft intern "select * from Tabelle"; soll ich beim Zeichnen des Autos die Reifen dann weglassen ????

Das Beispiel ist gut. Jedes CAD-Programm das genau nach deiner Logik arbeiten würde, würde von den Konstruktreuren dem Hersteller um die Ohren gehauen.

Ein gutes CAD-Programm würde auch wenn man "Lade PKW" dafür sorgen das es erstmal reduzierte Geometriedaten laden und PMI-Daten erstmal komplett weg lassen. Erst wenn der Konstrukteur in spezielle Bereiche hineinzoomt oder weiter Informationen will würde das CAD-Programm weitere Infos nachladen.
Aber NIEMALS (!) auf der Oberen Ebene alle verfügbaren Informationen

Mir fehlt hier hier auch ein wenig Kompromiss-Bereitschaft des Thread-Starters !

Nach allen bisherigen Postings ist es doch wohl klar, dass sein Weg nicht der richtige sein wird. Ein wenig Umstellung (oder auch mehr) auf einen anderen Algorithmus, die Verwendung von Queries (natürlich mit parametrisiert) und schon läuft dieser Job !

In meinen bisherigen Projekten waren immer Sachen wie "SELECT * FROM ..." oder eben ohne WHERE-Klausel schon ein Infrage-Stellen der fachlichen Fähigkeiten, oder eben des Willens etwas dazu zu lernen. Und der gesunde Menschen-Verstand eines Projektleiters sagt dann auch: ehe irgendetwas aufgerüstet wird, wird erstmal der Code gecheckt, ob da vielleicht was schief läuft ...

In diesem Sinne, viel "Spaß" mit 3 Mio Records in einer Table ...

Zitat von bernhard_LA:

sorry Jungs : das Hinterfragen ob ich wirklich 3 Mio Datensätze brauche ist sinnlos, es sind heute in unserem Problem-Projekt 3 Mio records - können aber auch mal deutlich mehr werden;

Das ist nicht Sinnlos. Das ist genau das was du dir fragen sollst.
Wenn du dir dies wichtige Frage nicht stellst, stellst sich mir die Frage ob du die geeignete Person bist dieses Problem zu lösen.
Evtl. sollte sich jemand mit dem Problem beschäftigen der sich mit dem eigentlichen Problem beschäftigt ob 3 Mio-Datensätze dem User gleichzeitig darstellen willst.

Solltest du wirklich 3 Mio. Daten "benötigen" z.B. um irgendwas zu exportieren, zu Analysieren so gibt es die Möglichkeit z.B. mit einem Forward-Only-Curser zu arbeiten oder "Wiederaufsetzende" Queries zu implementieren (Sortierte Abfrage und Blockweises abfragen und dann mit nächsten Block weiter machen).

Also (Hab die aktuellen Entwicklungen nur überflogen)

1. Keine Sau braucht 3 Mio Records *AUF EINMAL* im Speicher.
2. Wenn du alle Daten irgendwie brauchst, dann => paging. Leider ist das mit Delphi und einem TDataset nicht sooo leicht hinzubekommen, vor allen Dingen dann nicht, wenn geändert werden soll, aber egal.

Wenn Du alle Daten benötigst (und es gibt Fälle, da braucht man das, z.B. Export-Funktion oder eben Rendern), dann lade die Daten happenweise. Du kannst ja z.B. immer nur so viel laden, wie in ein Grid passen (ohne Scrollbars). Anstatt Scrolling hast Du die Buttons 'Seite vor', 'Seite zurück'. Dann noch '1. Seite' und 'Letzte Seite'. Und noch 'Gehe zu Datensatz #' etc.

Deine Tabelle muss ordentlich indexiert sein, damit Du auch bei er Query wie

markieren

Code:

select * from Tabelle where SchiessmichTot='Alu' and Nutenverwutzung in ('parsipal','konträrinhärent')

nicht stundenlang warten musst.

Das ist alles ein wenig Arbeit, aber irgendwann musst Du eh damit anfangen.

Ich habe (in C#) so ein Teil ein paar Stunden gebastelt. In Delphi würde ich das mit einer TListView auch so schnell hinbekommen (sogar mit einem MRU-Cache)

Das kürzt die Diskussion vielleicht ab. Was den Fehler anbelangt: Ich kenne ihn nicht, aber ich lade mir auch keine langen Tabellen in den Speicher und was man so liest, scheint es daran zu liegen.

Also: Gugel nach "Paging", implementier das und fertig. Wenn Du da nicht weiter kommst, frag nach.

Also Du hast vielleicht Zeitdruck oder nicht genügend Sachkenntnis oder oder
Man muss hier 2 Dinge unterscheiden, Ursachenforschung und Problemlösung. Das eine geht nicht ohne das andere, auch wenn Dich die 64 GB vielleicht über den Tag retten.

Deine Antworten sind leider zu unspezifisch für eine Hilfe.
"12 Mio Datensätze ging auch schon" sagt bspw. nichts über den Inhalt aus. Waren es die gleichen Datensätze wie die 259..., die nicht funktioniert haben?
Wenn Du kein Speicherplatzproblem hast, dann vielleicht ein Problem mit den Inhalten, also einzelnen Feldwerten. Das ist bei ADO ein typisches Problem. Hier kommen dann u.U. auch Treiberversion ins Spiel.

Vielleicht überlegst Du Dir einfach nochmal, wie man der Sache auf den Grund gehen könnte, lieferst brauchbare Informationen und stellst gute Fragen.

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
b) als der nächste Verdächtige (unser DB Admin) sich in erfolgreich aus der Schlinge befreien konnte (Meeting Dauer < 30 min )
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.


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

a) Stellen gefunden an denen das Problem simple umgangen werden kann ("hätte man schon längst machen sollen...")
b) an den meisten anderen Stellen ist es mit Aufwand machbar ("wenn schon refactoring dann jetzt komplett ....")
c) es gibt noch Stellen wo wir aktuell keine "universelle Lösung" sehen ("wenn es leicht wäre könnte es ja jeder machen ....") Unangenehm weil heute zeitlich nicht eingeplant und nicht Abschätzbar im Aufwand

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: