MSSQL/ADO + 3 Mio Datensätze , Thread Error

[p80286]

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

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von bernhard_LA (Beitrag 1262069)

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

Wirklich? Bezweifle ich.

Zitat:

Zitat von bernhard_LA (Beitrag 1262069)

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

[TRomano]

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

[Bernhard Geyer]

Zitat:

Zitat von bernhard_LA (Beitrag 1262075)

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

[Dejan Vu]

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

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.

[jobo]

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.

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

[Bernhard Geyer]

Zitat:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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?

[Dejan Vu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1262109)

Zitat:

Zitat von bernhard_LA (Beitrag 1262105)

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:

Zitat von bernhard_LA (Beitrag 1262105)

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

Delphi-Quellcode:

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.

[TRomano]

@Dejan Vu: :thumb:

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

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1262126)

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:

Zitat von mkinzler (Beitrag 1262126)

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

[mkinzler]

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

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1262145)

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.

[mkinzler]

Für die angezeigten schon

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1262151)

Für die angezeigten schon

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

[pertzschc]

Zitat:

Zitat von mkinzler (Beitrag 1262151)

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. :thumb:

Christoph

[Bernhard Geyer]

Zitat:

Zitat von pertzschc (Beitrag 1262228)

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:

Zitat von pertzschc (Beitrag 1262228)

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:

Zitat von pertzschc (Beitrag 1262228)

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?

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

[p80286]

Zitat:

Zitat von -=ZGD=- (Beitrag 1262239)

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

[Dejan Vu]

Zitat:

Zitat von -=ZGD=- (Beitrag 1262239)

Kann man die Daten nicht einfach häppchenweise lesen?

Es wurden so ziemlich alle Möglichkeiten schon vorgeschlagen. Happenweise, Paging, Cursor, Googeln. Alles.

[-=ZGD=-]

Zitat:

Zitat von Dejan Vu (Beitrag 1262247)

Zitat:

Zitat von -=ZGD=- (Beitrag 1262239)

Kann man die Daten nicht einfach häppchenweise lesen?

Es wurden so ziemlich alle Möglichkeiten schon vorgeschlagen. Happenweise, Paging, Cursor, Googeln. Alles.

Das war auch mehr auf den Thread-Ersteller gemünzt ;-)